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Abstract 


This report describes a framework for the specification of acquisition models. The 
exposition is formal in nature. The framework is defined in terms of activities, 
events, requirements, and instances of a system. In addition, various relations 
among these items, such as the relation between acquisition activities and acqui¬ 
sition events, are defined. The timing properties associated with the items receives 
special treatment. 

The value of a framework is that one can develop specifications of various acquisi¬ 
tion models, such as waterfall, spiral, or incremental, as instances of that frame¬ 
work. Formalizing the specification of an acquisition model has benefit in that one 
can reason about the characteristics of the domain addressed by the model. When 
this is done for multiple acquisition models, each derived from the same frame¬ 
work, it is possible to compare different acquisition approaches. 
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Executive Summary 


System acquisition—the set of activities performed to procure, develop, and main¬ 
tain a system—is a daunting challenge. This is particularly true for large, complex 
systems. There is ample evidence of routine cost and schedule overruns, not to 
mention acquisition failures. 

As acquisition has increased in scale and complexity, new approaches have been 
developed to meet the challenges. Such approaches to acquisition are based on 
some model. For many years a waterfall model was applied (largely in a develop¬ 
ment context), although now one hears of spiral, incremental, and evolutionary ac¬ 
quisition models. Although such models are popular, they are often lacking in a 
precise specification. 

Our goal in this report is to develop a specification of a general acquisition frame¬ 
work. The key elements of the framework are activities, events, requirements, and 
instances of a system. In addition, various relations among the key elements, such 
as the relation between acquisition activities and acquisition events, as well as 
timing properties, receive special treatment. We believe that from a specification 
of a framework, one can develop specifications of a particular acquisition model as 
an instance of that framework. This in turn allows one to perform a formally based 
comparison of various acquisition models, although to do so, we recognize it may 
be necessary to extend the specification of the framework to treat characteristics 
unique to a particular model. 

The approach to the specification of the framework is mathematical in nature. The 
value of such a formal approach is that it provides a clear, consistent, concise spec¬ 
ification of the framework. We believe there are additional practical benefits that 
can be obtained as a result of a formal specification of a framework and the speci¬ 
fication of models based on that framework. For example, we believe it should be 
possible to use the framework developed here as a means to develop practical pol¬ 
icies, procedures, and guidelines that can help acquisition managers. With the 
framework as a basis, it is possible to identify relevant acquisition activities and 
their associated events that are of interest to an acquisition manager. In addition, 
the timing properties concerning when acquisition activities are performed can 
also be addressed. But first things first. 
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1 introduction 


Recent years have witnessed the development of different approaches to system 
acquisition. For many years, a waterfall approach was common, but that was su¬ 
perseded by other approaches. Currently a number of different approaches are 
popular, including spiral, evolutionary, and incremental. However, many such ap¬ 
proaches are only loosely specified, rather than presented on a well-defined foun¬ 
dation. 

We define acquisition to be the set of activities performed to procure, develop, and 
maintain a system. This takes a broad view of acquisition. Some might prefer to 
equate acquisition with contracting activities, but we feel such a view is too limit¬ 
ing. Further, our concern is for the life of a system, not just from initiation to con¬ 
tract award, or just development. 

All acquisition is performed in the context of some overall model, whether or not 
that model is clearly specified. The use of an explicit acquisition model helps guide 
an acquisition project in the manner in which the acquisition is conducted. Despite 
the prevalence of popular acquisition models such as those mentioned above, we 
have not seen a clear, precise specification of these various models. The lack of a 
well-specified model has numerous consequences. Among them, we mention the 
possible confusion that may arise when one attempts to conduct an acquisition 
based on a loosely specified approach. 

Intended Audience 

The intended audience for the material presented in this report consists of persons 
interested in 

• how one specifies a framework that can be used to describe 
different acquisition models 

• using the framework specified here to develop a formal 
specification of a particular model 

• comparing different acquisition models 

In addition, because the specification developed here is formal in nature, persons 
with an interest in formal approaches may also gain value from it. We recognize 
that persons who are managing an acquisition project may not approach their 
problems from a mathematical perspective. To aid the reader, in Appendix B we 
provide some background on the language and approach used in this report. 

Certainly there has been much work done that is oriented toward various facets of 
software development processes. Examples of this include the Rational Unified 
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Process (RUP)} as well as development of standards for the software life-cycle pro¬ 
cess [4]. Our work differs from these, and others, in that our focus is toward formal 
specification of an acquisition framework that can then be used to develop partic¬ 
ular acquisition models. 

Acquisition Frameworks and Models 

Our goal here is to develop an acquisition framework that may be applied to the 
specification of different acquisition models. The acquisition framework is a gen¬ 
eral specification of 

• acquisition activities 

• acquisition events 

• requirements^ 

• instances of a system 

• relations among the above entities, such as between activities, and 
among activities and events 

• operational semantics (especially timing properties) arising from 
activities and events and their relations 

The acquisition events may be internal or external, depending upon whether they 
are initiated within or outside the scope and control of the acquisition project. 

Using the acquisition framework, it is possible to define an acquisition model as 
an instance of that general framework. We recognize that a particular acquisition 
model may require additional concepts and details that are not included in the 
framework. Inclusion of such model-specific information supplements the specifi¬ 
cation of the framework. 

Use of Formal Approach 

Our approach to specifying the framework will be formal in nature.^ The use of a 
formal approach allows us to develop a clear, concise specification of the semantics 


See http://www.rational.com/products/rup/index.jsp. 

At first, the reader may find it surprising that requirements are included in the framework. 
The reason for inclusion of requirements will be made clear in Section 2.3.3 on page 20. 

We will use a second-order predicate calculus that is under development and known as 
Nestor. Readers who have general familiarity with predicate calculus or with formal lan¬ 
guages such as Z should not have difficulty reading the specification developed here. 
Where necessary, we will provide notes to explain the language semantics. Appendix B 
contains an overview of the language used to develop the specification of the framework. 
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of the acquisition framework. From this common framework, different acquisition 
models can be developed. The resulting models, also formal in their specification, 
gain the advantages of a formal specification of the framework, e.g., clarity and 
precision of specification. Further, the use of a formal specification allows us to 
compare different models and gain deeper understanding of the fundamental 
characteristics of a given model. Thus, the use of a formal approach allows us to 
develop a solid foundation on which to reason about the domain of acquisition. 

We further believe that as acquisition becomes more complicated, so does the un- 
derl3dng model, though the model is often not fully defined. It is hoped that a for¬ 
mal approach will allow for a greater understanding of the semantics of different 
acquisition models. The use of a formal approach is valuable to analyze the de¬ 
scription of a specification, whether it be for a model of a software system or a mod¬ 
el of an acquisition. 

We admit that the amount of effort to develop formal specifications is nontrivial. 
But this is like any other formal specification: it takes time to develop an under¬ 
standing of the textual description and then to architect and cast that in a formal 
manner. One response to the approach taken here might be to reject it outright be¬ 
cause it forces one to address details that one would perhaps rather not. Our reply 
is that acquisition models deserve the same treatment that is expected of systems: 
their specifications should be clear, concise, consistent, and correct. We should ex¬ 
pect no less of the specification of an acquisition model! 

Practical Considerations 

Although the approach taken in this report is mathematical in its presentation, we 
believe there are several practical benefits. From a well-specified framework, one 
can develop a well-specified model for a particular acquisition approach. From a 
well-specified model, it should be possible to develop policies, procedures, and 
guidelines that are based on a sound foundation. 

For example, the framework defined here includes a specification of the notion of 
an activity. Some practical issues that arise when managing a real acquisition 
project that need to be considered are: 

• What are the activities that will be performed? 

• How does a given activity relate to other activities? 

• Are there criteria that must be satisfied in order to initiate an 
activity? If so, what are they? 

• Are there criteria that must be satisfied in order to terminate an 
activity? If so, what are they? 

• Can two different activities be performed at the same time? 
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Resolution of questions such, as the above are of importance to the practical man¬ 
agement of an acquisition. Recognition of such questions is derived from the spec¬ 
ification of a framework and its associated instance for a particular acquisition 
model. In Appendix C we provide some guidance on how the framework may be 
used to specify a particular model. Associated with the specification of the model 
there can be corresponding guidelines, policies, and procedures relating to how the 
model is implemented. 

A question related to the specification of an acquisition model is the execution of 
that specification. That is, given the specification, how is it performed, by mem¬ 
bers of an acquisition team that may include program office staff, contractors, and 
other organizations? A given specification of an acquisition model can be per¬ 
formed in different ways. Our focus here, however, is with the development of a 
specification more than the execution of that specification. 

Organization 

This report is organized in the following manner. The following section contains a 
specification of the acquisition framework. In Section 3 we illustrate an applica¬ 
tion of the framework to a waterfall model. Then, in Section 4 we provide some 
general discussion about various acquisition approaches and the utility of a formal 
specification. Several topics that are possible extensions to the framework are de¬ 
scribed in Section 5. A brief summary of the report appears in Section 6. 

A number of appendices accompany this report. Appendix A provides a summary 
of the mathematical exposition of the framework. Appendix B provides a brief tour 
of the language ATesfor, which is used to develop the specification of the acquisition 
framework. Appendix C provides guidance for those who may be interested in us¬ 
ing the framework developed here to specify a particular acquisition model. Ap¬ 
pendix D provides some additional discussion concerning a specification of the 
waterfall model. Finally, Appendix E contains an index of the mathematical oper¬ 
ations and data types that are present in the report. 

We gratefully acknowledge discussions with colleagues Jim Smith, Patrick Place, 
Eileen Forrester, Rick Barbour, and Jack Ferguson. 


'*• A relevant analogy is the following: There is a difference between the specification of a 
computer program (the code) and the manner in which that specification may be executed. 
For example, the code can be executed on a single processor or multiple processors in par¬ 
allel. 
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In this section we will describe the specification of the acquisition framework. This 
includes specification of data t 5 q)es, relations, predicates, and timing properties. 
We will also describe some completeness requirements placed on the framework. 
As part of developing the specification of the framework, we will show some small 
examples to indicate how the framework can be used to develop particular acqui¬ 
sition models. 

2.1 Data Specification 

The development of the specification for the acquisition framework will begin by 
considering various data types that will be used. (Some bacl^round on data types 
in Nestor can be found in Section B.2 on page 91.) 

2.1.1 Activities 

To begin, we need to specify a general acquisition activity. We write this as a free 
type declaration: 

[ACTIVITY] 

We want to deal with sets of acquisition activities. These are declared as: 
Acq_ActivitieS[(]: {ACTIVITY} 

The presence of the subscripted [t] denotes that the data object is d 3 mamic. That 
is, the elements of the data object change in time. If a data object is declared with¬ 
out such a notation, it means it is static and its elements cannot change with time. 

We also require that the set of acquisition activities must not be emptyIn other 
words: 

#Acq_ActivitieS[t] > 0 (2-1) 

As a brief example of how activities may be used in the specification of some acqui¬ 
sition model, the following illustrates how some activities can be declared: 


One might argue that the set of acquisition activities should be aliowed to be empty. How¬ 
ever, were that to be the case, there would be no modei! 
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Requirenients_Management, 

System_Design, 

System_Test, 

Risk_Management, 

Contract_Management, 

System_Maintenance, 

System_Deployment, 

Budget_Planning: ACTIVITY (2 2 

We can represent the above activities as a set by writing 

Acq_ActivitieS[tj = {Requirements_Management, System_Design, System_Test, 
Risk_Management, Contract_Management, System_Maintenance, 

Systein_Deployment, Budget_PIanning} 

Furthermore, suppose we were interested in separating the above activities into 
development activities and management activities. We can do this by declaring 
two sets and then requiring that they be disjoint, as follows: 

Development_ActivitieS[t] = (Requirements_Management, System_Design, System_Test, 
Systein_Maintenance, System_Deployment} 

Management_ActivitieS[t] = {Risk_Management, Contract_Management, Budget_Planning} 
Development_ActivitieS[t] n Management_ActivitieS[t] = 0 

2.1.2 Events 

The second major element of the framework is the notion of an event. It is impor¬ 
tant to distinguish between internal and external events. The differentiation is 
based on whether an event is initiated within or outside the scope of a particular 
acquisition project, respectively. We declare the following two basic data types: 

[INTERNAL_EVENT, EXTERNAL_EVENT] 

We can also declare sets of these events as: 

IntemaLEventSftp {INTERNAL_EVENT} 

ExternaLEventSpj: {EXTERNAL_EVENT} 


It is assumed that the set of external events represents those external events that 
are relevant to a particular application of the framework to a given model. We re¬ 
quire that the set of internal and external events do not have any events in com¬ 
mon. Mathematically, this requires 

IntemaLEventSft] n ExtemaLEventS[,] = 0 (2 3 ) 
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Note that we do not place a restriction on the cardinality of the sets of internal and 
external events. For example, one model may deal with external events, while an¬ 
other may not. Hence, specifying in the froTnework a cardinality restriction on 
events would be considered over-specification. 

To illustrate an application of internal and external events, here is an example of 
some internal events: 

Requirements_Review_Scheduled, 

Budget_Reviewed, 

Design_Review_Initiated, 

Contract_Award: INTERNAL_EVENT 

Note that each of the above is an event that is within the scope of an acquisition 
project, in the sense that the project controls when the event happens, as well as 
what other activities may be performed in response to that event. 

External events, on the other hand, are those that are initiated outside the scope 
of an acquisition project. The following is an example of how we could declare some 
external events: 

New_Standard, 

Standard_Revision, 

Standard_Withdrawal: EXTERNAL_EVENT 

New_COTS_Product, 

COTS_Product_Upgrade_Available, 

COTS_Product_Unsupported: EXTERNAL_EVENT 

We have separated the above external events into those dealing with standards 
and commercial off-the-shelf (COTS) products, respectively. We do this so that we 
can reason about each of them independently. 

2.1.3 Requirements 

One characteristic of an acquisition is that the resulting system must satisfy a 
specified set of requirements. To develop this notion in the framework, we intro¬ 
duce a free type to denote a requirement, namely: 

[REQUIREMENT] 


2 Framework Specification 

2.1 Data Specification 




A set of requirements is simply represented as® 

Requirements^]: {REQUIREMENT) 

We require that the set of requirements be non-empty, that is 
#RequirementS[t] > ^ 


Examples of how requirements may be declared are similar to the preceding dis¬ 
cussion of events. For example, we can declare some set of requirements as follows: 

Database_Requirements, 

Security_Requirements, 

Fault_ToIerance_Requirements: REQUIREMENT (2 4) 

When we introduced the data t 5 rpe to represent a requirement, namely require¬ 
ment, we did so without further comment. Our assumption in developing the 
framework is that a requirement is atomic in nature. This is tantamount to a well- 
specified condition. For example, we do not assume that a requirement is con¬ 
tained in some other requirement. Removing the atomic-like nature of a require¬ 
ment would require a different approach to the development of the framework, 
e.g., additional operations would be necessary to separate a given requirement 
into Its constituent sub-requirements. In practice, requirements may not always 
be specified in such an ideal way; in the framework we may remove such a condi¬ 
tion. We would argue, however, that requirements specified in an atomic-like 
manner should be a goal of an acquisition project. 

2.1.4 System 

There are many ways in which an acquired system can be realized. In particular 
there can be multiple instances of a system, each with perhaps different function¬ 
ality. Another choice is for there to be an instance of a system, which then evolves 
in time, as a result of changes to its requirements. To accommodate these various 
options, we simply introduce a free type 

[SYSTEMJNSTANCE] 


Recognizing that a given acquisition may produce, either initially or as a result of 
Its evolution, multiple instances of a system, we represent these different instanc¬ 
es as a set: 


6 

Note that the choice of a set (as opposed to a bag) guarantees uniqueness of the require¬ 
ments; i.e., there are no duplicate requirements. 


8 


2 Framework Specification 

2.1 Data Specification 




Systenift]: {SYSTEMJNSTANCE} 

We do not require that the set System must be non-empty; that is we do not require 
#System > 0. The reason is that initially, the set System may indeed be empty. 

As a simple example, consider the case where a system is being developed in a se¬ 
ries of (incremental) builds. Suppose it is intended that there will be three builds. 
Each build represents an instance of the system, and we can declare 

Build_l, Build_2, Build_3: SYSTEMJNSTANCE (2.5) 

We emphasize that the above specification is that for data t 5 q)es and not function¬ 
ality associated with those data tjrpes. For example, we recognize that the func¬ 
tionality of an instance of a system could overlap with other instances of that 
system. Nothing in the preceding would prevent such a functional specification 
from being developed. 

2.2 Relations Among Basic Eiements 

There are a number of relations that can be defined with respect to the acquisition 
activities, events, requirements, and system instances that are the basic data 
t 5 rpes used in the framework. Relations help to associate, or couple, the basic data 
t 5 q)es (some background on relations in iVestor can be found in Section B.3 on page 
94). Some guidance on the specification of these relations is provided in Table 2-1. 



Activities 

Events 

Require¬ 

ments 

System 

Activities 

Section 2.2.1 

Section 2.2.2 

Not specified 
in framework 
(see Section 
2.2.4) 

Not specified 
in framework 
(see Section 
2.2.4) 

Events 


Not permitted 

Not specified 
in framework 
(see Section 
2.2.4) 

Not specified 
in framework 
(see Section 
2.2.4) 

Require¬ 

ments 



Not specified 
in framework 
(see Section 
2.2.4) 

Section 2.2.3 

System 




Not specified 
in framework 
(see Section 
2.2.4) 


Table 2-1: Guide to Framework Relations 
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Of the possible relations one could construct, we need only be concerned with those 
along the diagonal or the upper diagonal indicated in Table 2-1. Note that the 
framework does not permit relations among events; it is assumed that events are 
always coupled to an activity. 

2.2.1 Relations Among Activities 

First, we will define a relation between two acquisition activities. The require¬ 
ments that we impose on this relation are as follows: 

• ^ given activity may be related to one or more activities. 

• Every activity must be related to at least one other activity. 

• An activity cannot be related to itself. 

The relation satisfying the above requirements is specified below: 

Activity_ReIation: Acq_Activities[t] <—> Acq_ActivitieS[ij 
V 3;, aj G Acq_ActivitieS[,] 

• Activity_ReIation (a; aj) 

( 2 . 6 ) 

An example of this relation is shown in Figure 2-1. 


Acquisition_Activity 



Figure 2-1: Interaction of Acquisition Activities 

The characteristics of the relation, represented by the S 3 rmbol “<—>”, indicate 
that the relation is total over both the domain and range (i.e., the relation must be 
defined for all elements of the set of acquisition activities). It furthermore indi¬ 
cates that the relation is many-to-many. In other words, a given acquisition activ¬ 
ity may relate to multiple other activities, and, furthermore, a given acquisition 
activity may be related to multiple other activities. 

For example, consider the activities declared in Eq. (2.2). To indicate that there is 
a relation between the activities requirements management and system test we 
simply write: ’ 
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Activity_Relation (Requirements_Management, System_Test) 


As another example, suppose we wanted to declare relations between risk man¬ 
agement and both system design and system test. We can write these as 

Activity_Relation (Risk_Management, System_Design) 

Activity_Relation (Risk_Management, System_Test) 

In reality we would need to specify more relations. Although it is practical to do so, 
it is required by the framework in the manner in which the relation in Eq. (2.6) is 
declared. In particular, Eq. (2.6) requires that every activity be related to at least 
one other activity. This can be viewed as imposing a conformance requirement on 
all acquisition models that claim to conform to the framework. 

2.2.2 Relations Among Activities and Events 

The next relation that we need to specify is that involving events and acquisition 
activities. First, we specify this for the internal events by defining: 

Internal_Event_Activity_Relation: Intemal_EventS[t] <—1-> Acq_Activities[t] 

V ejS IntemaLEventSft] • 3 ajG Acq_ActivitieS[t] 

• Internal_Event_Activity_Relation (Cj aj) (2.7) 

This mapping is shown in Figure 2-2. 


Internal Events Acqulsltion_Activity 



Figure 2-2: Mapping Internai Events to Acquisition Activities 


The basic requirements for the mapping of internal events to acquisition activities 
include the following: 

• Every internal event must be mapped to some acquisition activity; 
this is a completeness requirement. 

• The same internal event can be mapped to different acquisition 
activities. 

• Not all acquisition activities are required to be associated with 
some internal event (i.e., the relation is partial over the range). 
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For example, earlier we specified an internal event for budget review and an ac¬ 
tivity for budget planning. Using the above relation, we can declare a relation be¬ 
tween these two as follows: 


InternaI_Event_Activity_ReIation (Budget_Review, Budget_Planning) 

Or suppose one wanted to have a budget review associated with the activity of a 
design review; we can declare this by 

lnternaI_Event_Activity_ReIation (Budget_Review, Design_Review) 

The second group of relations included in the framework are those that relate ex¬ 
ternal events and acquisition activities. This mapping is defined as 

ExternaLEvent_Activity_Relation: Extemal_EventS(,] <-|—1-> Acq_Activities[,j 
a Cj e Extemal_EventS[t], aj € Acq_ActivitieS[t] 

• ExternaI_Event_Activity_Relation (c; aj) (2.8) 

We show the character of this mapping below. 


External Events Acquisition_ActivIty 



Figure 2-3: Mapping External Events to Acquisition Activities 

^e relation given in Eq, (2.8) is very similar to that in Eq. (2.7). However, there 
is an important difference. In Eq. (2.8), the relation for external events need not 
be defined for all possible external events that can exist outside the scope of the 
project. Mathematically, the relation is partial over the domain, rather than total. 
The choice for having the relation be partial over the set of external events simply 
recognizes that there may be external events that may not be of relevance to a par¬ 
ticular acquisition project. For example, the existence of a new COTS product (an 
event) that is not relevant to a particular acquisition is not an external event of 
interest to the project. 

To illustrate how the relation between external events and activities may be used 
in a particular model, suppose we wanted to declare a relation between a revision 
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of a standard and the activity associated with requirements management. We can 
write this as 

ExternaI_Event_Activity_ReIation (Standard_Revision, Requireinents_Management) 

Similarly, we may also want to relate the existence of an upgrade of a COTS prod¬ 
uct to requirements management. This would be declared by the relation 

External_Event_Activity_Relation (COTS_Product_Upgrade, Requirements_Management) 

2.2.3 Relations Between Requirements and System Instances 

A feature that distinguishes one instance of a system from another is the require¬ 
ments a given instance must satisfy. This suggests, and practicality dictates, that 
there is a function that relates requirements to one, or possibly more, instances of 
a system. In the present case the relation must satisfy the following: it must per¬ 
mit that 

• a given requirement may be mapped onto one, or possibly more, 
instances of a system 

• there may be more than one mapping of a requirement onto either 
one or more instances of a system 

• each requirement must be mapped to some instance of a system 

The result of the preceding is that the mapping of requirements is many (require¬ 
ments) to many (system instances). It is, furthermore, total over both the domain 
and range. 

The mathematical representation of the preceding relation between requirements 
and a system is defined as 

Requirements_Mapping: RequirementS[t] <—> System^f] 

V q £ RequirementS[t] • V Sj € System[t] 

• Requirements_Mapping (q _ Sj) (2.9) 

One example of the relation between requirements and a system is shown in Fig¬ 
ure 2-4. Here, we show a set of requirements that are associated with one instance 
of a system. Note also that, in this particular case, the mapping is many-to-one; 
that is, each requirement is mapped to only one instance of the system. 
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Figure 2-4: Mapping Requirements to a Single System Instance 

A second example is shown below in Figure 2-5. Here, there are two instances of a 
system, denoted 1 and 2. Note that some of the requirements are mapped to each 
instance of the system, while others are only mapped to one instance of the system. 



Figure 2-5: Mapping Requirements to Multiple System Instances 


The relation indicated in Figure 2-5 can represent two different alternatives. 
First, it may be the case that there are two distinct (unrelated) systems that hap¬ 
pen to satisfy the requirements as indicated. A second alternative is that System 
1 satisfies a subset of the total requirements, which then evolves to satisfy the oth¬ 
er requirements, resulting in System 2. There is not sufficient information speci¬ 
fied in the figure to determine which of these two alternatives is intended. 

Let us illustrate the notion of requirements mapping. Earlier, in Eq. (2.5) we de¬ 
clared three builds as being instances of a system. We had also identified some re¬ 
quirements (see Eq. (2.5)). Suppose we wanted to specify that the database 
requirements are related to build 1 and the security requirements are related to 
build 2. We can specify these relations as: 

Requirements_Mapping (Database_Requirements, Build_l) 

Requirements_Mapping (Security_Requirements, Build_2) 
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We recognize, from a practical perspective, that the preceding relations are not 
complete. The reason is that we have requirements for fault tolerance, and no re¬ 
lation for how these requirements are related to an instance of a system has yet 
been specified. This illustrates some of the practical considerations of applying a 
general framework to a particular model with regard to completeness of require¬ 
ments specification. Formal consideration of completeness criteria will be present¬ 
ed in Section 2.5 on page 25. 

2.2.4 Additional Considerations 

In developing the framework, we did not specify all possible relations involving the 
basic framework elements that are noted in Table 2-1 on page 9. The following pro¬ 
vides some brief rationale for the relations that were not specified. 

2.2.4.1 Activities and Requirements 

A relation between activities and requirements was not included in the framework 
because we felt it was at a lower level of specification, and thus is more relevant 
perhaps in the specification of a particular model. 

2.2.4.2 Activities and System Instances 

It could be possible to specify a relation between an activity and an instance of a 
system. The interpretation of such a relation might be that some activity is per¬ 
formed in the context of a particular system instance. For example, it may be re¬ 
quired to perform system test (an activity) for some instance of a system. However, 
we felt that such a specification was more relevant to development of a model than 
the framework. 

2.2.4.3 Events and Requirements 

It did not appear appropriate to specify a relation between an event and a require¬ 
ment. An example of how such a consideration may be of relevance is if the occur¬ 
rence of some event could cause a change to a requirement. This consideration can 
be handled by building on the relation between events and activities and then com¬ 
posing them with operations that couple activities and requirements. 

2.2.4.4 Events and System Instances 

The reason that a relation was not declared that relates events and em instance of 
a system is similar to that described above in Section 2.2.4.2. Further, events are 
coupled to activities that can then be related to operations performed on an in¬ 
stance of a system. 
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2.2.4.5 Requirements and Requirements 

The intended use of relations can be realized in different ways. That is, one can 
explicitly define a relation among requirements, or the same functional semantics 
can be achieved through the use of predicates. We chose to describe the relation 
among requirements using predicates to indicate, for example, that one require¬ 
ment may depend on another requirement (see further Section 2.3.3). 

2.2.4.6 System instances and System Instances 

Similar to the reasoning above, we have used predicates to indicate the relation 
between system instances. For example, we will later provide a mechanism to de¬ 
clare that one instance of a system depends on another instance (see further Sec¬ 
tion 2.3.4). 

2.3 Predicates 

The major building block for specification of operations in the language Nestor is 
A predicate. (Some background on predicates in Nestor can be found in Section B.4 
on page 96.) Predicates can be represented in a number of ways including 

• as a simple declaration: A simple example is a statement that a 
requirement has been tested. One can think of this as an axiom 
that is used to develop a specification. 

• presence of a pre-condition clause: A predicate can include a 
specification of the conditions that must be satisfied in order for the 
predicate to be true. Such conditions are known as pre-conditions. 

• presence of post-conditions: Given that a predicate has the value 
true, the post-conditions specify what happens under this 
circumstance. For example, one can say that if a requirement is not 
satisfied, then system testing is not completed. 

While predicates are primarily used to specify operations associated with a speci¬ 
fication, they can also be used as inquiry functions. In this case, one can declare a 
predicate that states that a requirement is satisfied. This fact (represented by the 
predicate) can then be used in the development of other predicates. A predicate 
may contain arguments; time is provided as a built-in capability. 

2.3.1 Activities 

Activities are a basic data type used in the specification of the acquisition frame¬ 
work. As such, it is useful to specify operations on the activities. Examples of this 
might include 
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• add an activity to the set of activities 

• modify an existing activity 

• remove an existing activity 

Using the specification of an activity, we can write predicates for each of the above 
as follows: 


Add_Activity (aj: ACTIVITY; t, t') Boolean 
\=> 

Acq_ActivitieS[t] = Acq_ActivitieS[t'] C* {a;} 
t>f 


( 2 . 10 ) 


In the above equation the parameters t and f are present as arguments; these in¬ 
dicate values of time, which is a built-in data type in the language iVestor. In effect, 
Eq. (2.10) states that at the time t, the specified activity is added to the set of ac¬ 
tivities that existed at a time t’, which must, of course, have been an earlier instant 
of time. 


Modify_Activity (aj: ACTIVITY; t) Boolean 

Delete_Activity (aj: ACTIVITY; t, t') —» Boolean 
1 ^ 

Acq_ActivitieS[t] = Acq_ActivitieS[,.] \ {aj} 
t>t' 


( 2 . 11 ) 


( 2 . 12 ) 


The first and third predicates above contain a specification of a post-condition. For 
example, if an activity is deleted, the result is that the specified activity should be 
removed from the set of acquisition activities. The second predicate has neither a 
pre- nor post-condition. It is interpreted simply as a declaration. 

Note that the predicates declared above are associated with a Boolean value. This 
indicates the result of application of the predicate. For example, in the case where 
we can modify an activity, defined by Eq. (2.11), if a specified activity is modified, 
then the predicate assumes the value true. Hence, consider: 

Modify_Activity (Requirements_Management; t) —> True 

The result of the above operation is that it assumes the value true. 

Each of the predicates specified above contains an argument (the s 5 Tnbol t ap¬ 
pearing after the semi-colon) which is used in Nestor to denote time. We include 
time in the specification of a predicate in order to account for the d 3 niamics of an 
acquisition. For example, we could use such an approach to state that after a cer¬ 
tain time no acquisition activity can be added to the set of acquisition activities. 
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The ability to specify the model d3mamics is fundamental to the specification of 
any acquisition. 


There are a number of inquiry functions that may prove valuable for the develop¬ 
ment of a particular acquisition model. These are provided below. 


Activity_Started ( 3 - ACTIVITY; t) -> Boolean 
ActivityJn_Progress (aji ACTIVITY; t) -> Boolean 
Activity_Suspended (aj: ACTIVITY; t) -> Boolean 
Activity_Completed (aj; ACTIVITY; t) Boolean 


(2.13) 

(2.14) 

(2.15) 

(2.16) 


IS m 


The above predicates are true at a time t if an activity has been started,_ 

progress, has been suspended, or is complete, respectively. The inquiry functions 
can be used to construct other statements. For example, consider the following 
question: If an acquisition activity is in progress, can that activity be deleted? We 
would hope that the answer is no.^’ ® 


2.3.2 Events 

In our basic declaration of events (see Section 2.1.2 on page 6), we provided for in- 
ternal and external events. The difference between these two events was whether 
the event was initiated within or outside the scope of an acquisition project. There 
are a number of predicates relevant to a description of both these classes of events. 

2.3.2.1 Internal Events 

We begin by considering internal events. We define a predicate to create an event: 


Incidentally, the answer to the question “if an acquisition activity is in progress, can it be 
deleted?” is no. The reason is that operations are assumed to be atomic in nature; that is 
once they start to execute, they complete without interruption. See Section B.6 on oaae 99 
for further discussion of this. ^ 

®- Some cases are fairly straightforward to develop, but there are subtle considerations one 
must account for. To digress a bit, consider the case where there is some external event. 
Assume further that the external event is related to some acquisition activity, as given by 
Eq. (2.8) on page 12. What behavior should an acquisition manifest if the activity associat¬ 
ed with the event is deleted? In other words, if an external event arises (such as the exist¬ 
ence of an upgrade to a COTS product that is used in a system) and there is no activity 
present to deal with the COTS product upgrade, what happens? Is the acquisition model 
specified correctly? It is through the use of not simply a formal mathematical language, but 
rather, the use of an approach that is based on formalism, logic, and completeness that 
leads one to develop (and consider) questions such as these. 
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Create_Internal_Event (e: INTERNAL_EVENT; t, t') —> Boolean 

l=> 

Intemal_EventS[t] = InteraaLEventSff] U {e} 

t>f (2.17) 

If this predicate is true it means that the specified internal event has been created 
at the time t. It is then added to the set of internal events. 

Another useful operation is to modify an existing event; we define this as 

Modify_Internal_Event (e; INTERNAL_EVENT; t) —> Boolean 

A third operation is that which deletes some internal event; this is specified as 

Delete_InternaI_Event (e: INTERNAL_EVENT; t, t') Boolean 
1 =^ 

Intemal_EventS[j] = Intemal_EventS[t'] 
t > f 

It is also helpful to specify a predicate that, if true, indicates that some internal 
event has occurred. This is a form of inquiry function, and we write it as 

Iiiternal_Eveiit_Occurred (e: INTERNAL_EVENT; t) Boolean (2.18) 

We also need to be able to initiate, or raise, an internal event. We write this as 

Generate_Internal_Event (e: INTERNAL_EVENT; t) —> Boolean 
|=> Iiiternal_Event_Occurred (e: INTERNAL_EVENT; t) 

In the preceding we have included a post-condition. That is, if some internal event 
is generated, it means that the predicate indicating that the event has occurred 
becomes true. 

2.3.2.2 External Events 

External events are those events that are specified in the context that lies outside 
of the scope of the acquisition project. At first one might think that we can simply 
replicate the operations associated with internal events, appropriately replaced 
instead by external events. However, such an approach is inappropriate. The rea¬ 
son is that from the perspective of the acquisition project, there are operations that 
can occur that are outside its scope. For example, the acquisition project cannot 
generate some external event. Instead, external events are generated by some 
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(unspecified) agent that lies outside the scope of the acquisition project.^ Including 
external events in the framework allows a coupling to items that are outside the 
scope of the acquisition project. 

One operation that can be specified is that which indicates some external event 
has occurred. We write this as 

ExternaLEvent_Occurred (ej: EXTERNAL_EVENT; t) Boolean 

3 aj: ACTIVITY • 

External_Event_Activity_Relation (e, aj) ( 2 . 19 ) 

Note the presence of a pre-condition here, in contrast to the corresponding opera¬ 
tion for internal events (see Eq. (2.18)). That is, we are only interested in the oc¬ 
currence of those external events such that they are related to an acquisition 
activity. In effect, the pre-condition clause serves to filter only the external events 
of interest to the acquisition project. 


2.3.3 Requirements 

Requirements management is a fundamental aspect of any acquisition, and the 
framework addresses requirements. One especially important consideration is 
that the ability to relate requirements to different instances of a system is of par¬ 
ticular importance in acquisition (think of the difference between a waterfall mod¬ 
el and an incremental mode, for example). 

The predicates that will be included in the framework to perform operations can 
be developed from those for dealing with activities (see Eq. (2.10) ff.). 

Add_Requirement (q: REQUIREMENT; t, f) Boolean 

l=> 

RequirementSft] = RequirementSf,] U {q} 

^ ( 2 . 20 ) 


Modify.Requirement (q: REQUIREMENT; t) -> Boolean 


( 2 . 21 ) 


One could attempt to develop a specification of some relevant aspects of the external en¬ 
vironment associated with some acquisition project. For example, one could develop a 
specification of a COTS marketplace. The integration of that specification and one based 
on the framework specified here would be achieved through the predicates defined here for 
dealing with such external events, as well as relations between the external events and the 
(internal) acquisition activities that are performed. Although the development of a specifi¬ 
cation for some externai aspects of acquisition may be interesting and challenging, they are 
beyond the scope of the framework specified here. For some discussion of an acquisition 
modei that includes COTS products, see [5]. 
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( 2 . 22 ) 


Delete_Requirement (rj: REQUIREMENT; t, t') —> Boolean 

RequirementSft] = Requirements[,•] \ {q} 
t>t’ 

There are other operations that can be performed on requirements and warrant 
consideration as part of the framework. First, it is useful to know if some require¬ 
ment has been satisfied. We can write a predicate for this as 

Requirement_Satisfied (q: REQUIREMENT; t) —> Boolean (2.23) 

A second operation deals with the specification of dependencies among require¬ 
ments. We can define this by the following predicate: 

Requirement_Dependency (q, rj: REQUIREMENT; t) —> Boolean (2.24) 

If the above predicate is true, it indicates that requirement ri depends on require¬ 
ment rj at a time t. For example, this could mean that requirement rj would have 
to be included in the system before requirement r^. Using Eq. (2.24) it is also pos¬ 
sible to develop requirements chains', that is, a sequence of dependencies. Thus, 
we could specify that requirement rj depends on requirement r 2 , which depends 
on requirement This ability may be useful, in particular, to evolutionary acqui¬ 
sition models. 

Given the ability to specify a dependency between requirements, we need to spec¬ 
ify that there is not a pairwise dependency between requirements. In other words, 
if requirement x depends on requirement y, then we shall require that require¬ 
ment y cannot depend on requirement x. Such a statement must hold for all re¬ 
quirements and is written as: 

V q G Requirements • 

Requirement_Dependency (q, q; REQUIREMENT; t) 

=> 

—1 Requirement_Dependency (rj, q: REQUIREMENT; t) (2.25) 

The above is an expression in the language Nestor. It involves a quantification over 
all requirements and results in an assertion about the specification regarding re¬ 
quirements dependencies. As a practical application of this expression, suppose a 
specification of an acquisition model contained the following text: 

Requirement_Dependency (Security_Requirements, Security_Requirements; t) 
Requirement_Dependency (Security_Requirements, Security_Requirements; t) 

By virtue of Eq. (2.25) the preceding declarations would be invalid. 
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2.3.4 System 

We will define a predicate to indicate that some instance of a system depends on 
another instance of the system. This is written as 


System.Dependency (Sj, Sj: SYSTEM; t) -> Boolean 


(2.26) 


One of the important aspects of a system is in terms of how it relates to require¬ 
ments. We define an operation that indicates that a particular requirement is sat¬ 
isfied by some instance of the system. 

Requirement.Satlsfied (rj: REQUIREMENT, sj: SYSTEM; t) -4 Boolean (2.27) 

If the above predicate is true it implies that the specified requirement is satisfied 
by a particular instance of the system. The framework does not specify the details 
of how a requirement is satisfied, as this is more a property of the system. Howev¬ 
er, we would expect that if a requirement has been satisfied, most likely it would 
mean that some testing has been done to verify the requirement. 

Eq. (2.27) could be used to specify the time-phasing of requirements. For example 
if we have two requirements denoted rj and T 2 , then consider the following: 

Requirement.Satisfied (tj: REQUIREMENT, Sj: SYSTEM; t) 

Requirement_Satisfied ( 13 : REQUIREMENT, s,: SYSTEM; f) 

t' >t 

The above specifies that requirement rg is satisfied at a later time than require¬ 
ment rj. 

Finally, we can define a predicate that states that some instance of a system is sat- 
isned. The pre-condition for such a predicate is that every requirement that is as- 

sociated with a particular instance of a system must be satisfied. Mathematically 
we have ’ 

SystemJnstance.Satisfied (sj: SYSTEM; t) -» Boolean 


V Tj G Requirements • 

Requirements_Mapping (rj, Sj) • 
Requirement.Satisfied (rj; t) 


(2.28) 


In developing the preceding predicate we have used the relation between require¬ 
ments and instances of a system, Eq. (2.9), and the predicate to indicate that a 
specified requirement has been satisfied, Eq. (2.23). 
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2.4 Execution Character 


The specification developed thus far is largely static in nature. In reality, an ac¬ 
quisition has an execution characteristic, and we will now discuss this general top¬ 
ic. We will later develop several t 3 rpes of execution character that may be applied 
to a particular instance of the framework. 

2.4.1 Basic Execution Modei 

In developing the predicates for the temporal evolution of an activity we will use 
a state model. We consider the following states of an activity: null (the initial 
state), in_progress, suspended, and completed. The state transition diagram ap¬ 
pears in Figure 2-6. 


Meaning of State Transitions 

1 Activity is started 

2 Activity is completed 

3 Activity is suspended 

4 Activity is resumed 

5 Activity completes 


an Activity 

The state transition model shown in Figure 2-6 is simple, but it will serve our need 
for a specification in the framework. The first predicate we will declare is that 
which specifies the initiation of some acquisition activity. This is defined as 

Imtiate_Acquisition_Activity (aj: ACTIVITY; t) —> Boolean 

—I Activity_in_Progress (aj: ACTIVITY; t) 

l=^ 

ActivityJn.Progress ACTIVITY; t) (2.29) 

The presence of the pre-condition states that an acquisition activity cannot be ini¬ 
tiated unless it is not already in progress. The presence of a post-condition in Eq. 
(2.29) simply states that when an acquisition activity is initiated it is in progress. 

We will also provide the capability to suspend and resume an acquisition activity. 
These are defined as: 



Figure 2-6: State Transition Diagram 
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Suspend_Acquisition_Activlty (aj: ACTIVITY; t) -> Boolean 

3 t' < t • Initiate_Acquisition_Activity (aj: ACTIVITY; t ) 

l=> 

-1 ActivityJn_Progress (a;: ACTIVITY; t) 


(2.30) 


Note that there is a.pre-condition associated with suspending an acquisition activ¬ 
ity , namely, the activity had to be started at a previous time. Note also the post¬ 
condition: if an activity is suspended, it is no longer in progress. 

Resume_Acquisition_Activity (aj: ACTIVITY; t) -4 Boolean 


3 t' < t • Suspend_Acquisition_Activity {a,: ACTIVITY; t ) 
Activity_in_Progress (a;: ACTIVITY; t) 


(2.31) 


The predicate to resume an acquisition activity also has the pre-condition that the 
specified activity had to be suspended at an earlier instant in time. Also, the post¬ 
condition specifies that after an activity is resumed, it is now in progress. 

Similarly, we define 

Terininate_Acquisition_Activity (a,: ACTIVITY; t) -> Boolean 

3 t' < t • Iiiitiate_Acquisition_Activity (aj: ACTIVITY; t ) 

l=> 

-I ActivityJn_Progress (aj: ACTIVITY; t) (2.32) 

As an aside, note that the specification of the predicate for suspending an acquisi¬ 
tion activity is the same as the predicate for terminating an acquisition activity. 
When two predicates are identical we say that they are underdefined. This means 
that further specification, known as refinement, must be added to distinguish 
their semantics. In Section 5.8.3 on page 70 we will show how these predicates can 
be resolved by explicitly accounting for the state in their definition. Doing so re¬ 
moves the underdefined character of the specification. 

We may also combine the predicates that define the initiation and termination of 
an activity to specify the execution of some acquisition activity in the following 
manner: 
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Execute_Acqiiisition_Activity (aj: ACTIVITY; t, t') —> Boolean 
1 "^ 

Initiate_Acquisition_Activity (aj: ACTIVITY; t) 

Terininate_Acquisition_Activity (aj; ACTIVITY; t') 

t->t (2.33) 

The above predicate is defined in terms of two values of time t and t', which repre¬ 
sent the initial and terminal times associated with the execution of the activity, 
respectively. The predicate Execute_Acqviisition_Activity is true if and only if 
the predicates for the initiation and termination of the activity are also true. Note 
however, that it is possible for the predicate to be true even if the acquisition ac¬ 
tivity was suspended and resumed during the course of its execution. 

2.4.2 Concurrency Considerations 

A second facet to the execution of acquisition activities deals with the need to ad¬ 
dress concurrency considerations. It is a reality that acquisition frequently in¬ 
volves cases where multiple activities may be ongoing at the same time. In the 
framework it is thus relevant to specify operations related to concurrency. 

The first operation that we will define is one that indicates that two different ac¬ 
quisition activities may be concurrent in nature. This is expressed as 

Concurrency_Permitted (aj, aj: ACTIVITY) —> Boolean (2.34) 

The preceding predicate is assumed true if activities and aj are permitted to exe¬ 
cute concurrently. One may also want to define an operation that specifies that 
two activities may not be concurrent, and we can write this as: 

Concurrency_Prohibited (aj, aj: ACTIVITY) —> Boolean (2.35) 

It is also possible to develop an operation that is stronger in intent than that ex¬ 
pressed by Eq. (2.34). That is, there may be occasions where it is required that cer¬ 
tain activities execute concurrently; this can be expressed as 

Concurrency_Required (a,, aj: ACTIVITY) —> Boolean (2.36) 

2.5 Completeness Considerations 

It is important to assess whether an acquisition model is complete, and we will 
now develop an approach to this problem. Intuitively, it may appear clear what the 
notion of completeness means. However, one of the reasons for developing a formal 
specification is to be able to precisely define some aspect of a model. Hence, we will 
now formally describe what we believe is a reasonable definition of completeness 
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of a general acquisition model. There are two aspects to completeness: of the spec¬ 
ification and of an execution of that specification. 

2.5.1 Specification Completeness 

In pneral, the specification completeness indicates some property of the specifi¬ 
cation of an acquisition model as an instance of the framework. Several of such 
considerations have already been defined. For example, in the development of the 
relation between internal events and acquisition activities given in Eq. (2.7) on 
page 11 we required that every internal event must be related to some acquisition 
activity. This means that if an acquisition model declares an internal event, and 
that specified event is not related to some acquisition activity (through the speci¬ 
fication of an instance of the relation), then the model is not complete. 

As another example, we required that the sets of internal and external events have 
to be disjoint, i.e., have no members in common. This was defined in Eq. (2.3) 
where we stipulated: 

IntemaLEventSfi] o Extemal_EventS[t] = 0 

Hence, if a specification of a model had the same event in both sets, then the spec¬ 
ification of the model would be incorrect. 


To ifiustrate something that is not specified in the framework, we had considered 
adding a requirement that every acquisition activity had to be reachable from ev¬ 
ery other acquisition activity. This would mean there should be no “loose ends” in 
the way acquisition activities are related to each other. To assess the reachability 
criteria, consider the acquisition model “architectures” shown in Figure 2-7. 

In part (a) of Figure 2-7 an external event is related to an acquisition activity, as 
required in the framework as described in connection with Eq. (2.8). However, if 
we required that each activity be related to some other acquisition activity, that is 
illustrated in connectivity of the activities shown in Figure 2-7(a). In contrast, con¬ 
sider part (b) of Figure 2-7. As required, there is still a relation between the exter¬ 
nal event and an acquisition activity. However, in this case, the indicated 
acquisition activity is not related to any other activity. Instead, there is a relation 
to an internal event, which then serves as an intermediary to other acquisition ac¬ 
tivities. 
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External Events 



Activities 

(a) 



(b) 


Figure 2-7: Different Mechanisms for Handiing External Events 

Hence, if we required a reachability property over the set of acquisition activities, 
it would preclude an architectural model such as that in part (b) of Figure 2-7. For 
this reason, we have not included a reachability property in the framework. An ac¬ 
quisition model may, however, impose such a condition without adverse effect on 
the framework specification. For a further elaboration of this point, see the discus¬ 
sion dealing with conformance of a model to the framework in Section C.l. 


2.5.2 Execution Completeness 

There is a second view of completeness of a model, and that is with respect to the 
execution of the model. From a practical perspective, we are talking about the 
manner in which the model is performed. 

We begin by declaring two instants of time that denote an interval over which an 
acquisition takes place. These may be interpreted as the ‘ beginning and end of 
the acquisition. The declaration for these instants is 

^tart’ ^top’ Time 

From an operational view, we state that an acquisition model is execution-com¬ 
plete on the interval [tgtart^ ^stopl if following conditions are satisfied: 
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• The execution of acquisition activities is well specified on the 
interval. By this we mean that no activity starts before the time 
^startJ that all activities must be terminated prior to the time 

^stop- 

• For every external event that may be initiated in the interval and 
that is related to some acquisition activity, that acquisition activity 
must be initiated before the end of the interval. The preceding item 
further implies that the activity associated with the external event 
must also complete. 

• For every internal event that may be initiated in the interval, the 
event is related to some acquisition activity, and its associated 
acquisition activity is initiated. 

• For every requirement that exists at the end of interval tgtop, the 

requirement is satisfied. ^ 

Well Specified 

The criterion of well specified may be stated as 
V aj 6 Acq_Activities{t] 

3 h ^ kim • Initiate_Acquisition_Activity (a;: ACTIVITY; t,) a 
3 t 2 ^ tjtop • Tenninate_Acquisition_Activity (aj: ACTIVITY; 12 ) 

W < tstop (2.37) 

Note that the preceding does not mean that an activity cannot be suspended and 
then resumed (perhaps multiple times) during the interval [tgtart^ ^stopl- The key 
point is that the activity be terminated before the end of the time interval in con¬ 
sideration. 

External Events 

The next condition for execution completeness is that for those external events 
that may occur (as defined by the relation between external events and acquisition 
activities) during the interval, the associated acquisition activity must be initiat¬ 
ed. The necessary formalization of this condition is as follows: 


Thsre is one potential loose end, namely, if an external event occurs before the start time 
of the interval, but the acquisition activity that deals with the event does not start until after 
the beginning of the interval; hence, a possible overlap. However, as we shall see, if a mod¬ 
el is execution complete on an interval, then it is not possible for the above situation to occur 
on any other than the first interval. 
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V Cj G Extemal_EventS[t] • 

Time_of [External_Event_Occurred (Cj: EXTERNAL_EVENT; t)] e [tgtart’ ^stopl 
3 aj: ACTIVITY • 

External_Event_Activity_Relation (Cj aj) 

A 

Initiate_Acquisitioii_Activity (aj: ACTIVITY; t) 

I ^ E^start’ ^stop] 


(2.38) 


Note the presence of Time_of in Eq. (2.38). This is a built-in function in Nestor that 
extracts the time associated with the evaluation of its argument. In this case, the 
operation Time_of returns the value of time t associated with the operation 
External_Event_Occiirred; in other words, it returns the time when the exter¬ 
nal event occurred. 

We make an important note concerning Eq. (2.38). From Eq. (2.37) we see that if 
an acquisition activity is started on the interval, it must be completed. The speci¬ 
fication of Eq. (2.38) only states that the acquisition activity is started. However, 
it follows from these two equations that the activity associated with the external 
event must also terminate. This is an example of reasoning over a specification, 
which is an important consideration for more advanced work. 

Internal Events 

The next condition is that associated with internal events. This condition may be 
specified in a manner similar to that for external events, described above. We have 

V Cj e Intemal_EventS[t] • 

Time_of [ Internal_Event_Occurred (ej: INTERNAL_EVENT; t)] G [^start’ ^topl 
3 aj: ACTIVITY • 

Internal_Event_Activity_Relatioii (C; _ aj) 


Iiutiate_Acquisition_Activity (aj: ACTIVITY; t') 
t ^ l^tart’ ^topl 


(2.39) 


The interpretation of Eq. (2.39) is easily discerned from that described above for 
external events. 

Requirements 

Our final condition for execution completeness is that all requirements that exist 
at the end of the interval must be satisfied. This condition may be specified as fol¬ 
lows: 


V fj G RequirementSftstop] • 

Requirement_Satisfied (q; tg^^p) 


(2.40) 
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Note the power achieved through the use of the dynamic data t 3 ^e used to repre¬ 
sent requirements. In particular, Requirements[tg^p] denotes the members of the 
set of requirements at the time tgtop. We then simply require that each of these re¬ 
quirements must be satisfied. Note further, if a requirement is deleted before tstop 
then it will not be in the set Requirements and we need not be concerned with 
it. Furthermore, if some requirement is added prior to tg^op it will remain in the set 
(unless otherwise deleted) and must therefore also be satisfied. Hence, we do not 
care what changes are made to the set of requirements, either through addition, 
deletion, or modification. We simply require that all the requirements at the end 
of the interval must be satisfied. 

Summary 

TTie preceding has described an approach that allows us to specify that an execu¬ 
tion of some acquisition model is complete with respect to some time interval. We 
have developed this approach in terms of activities, internal and external events, 
and satisfaction of requirements. 

We have not addressed the seemingly innocuous question of when an execution of 
a model is entirely complete; i.e., when is it done? There are different ways to de¬ 
fine overall completeness, including when 

• all of the requirements are satisfied 

• all activities have terminated 

• the latter of the above completes 

Any of the above are reasonable definitions of when an execution of a model com¬ 
pletes. Because each is acceptable, we do not include, in the framework, a defini¬ 
tion of when an execution of a model is done. Instead, that choice is left to the 
developers of a particular model specification. 

We conclude by noting a practical benefit to the concept of execution completeness. 
For example, consider an acquisition model that is based on an incremental or spi¬ 
ral approach. When is an increment or spiral complete? It is the use of a specifica¬ 
tion such as presented above that allows us to address this concern. When recast 
in the context of an acquisition program, performed according to a particular ac¬ 
quisition model, then the question becomes very relevant in a practical sense. 


2.6 Summary 

By means of summary, and largely from an intuitive perspective, the following fig¬ 
ure summarizes the relations between acquisition activities, internal and external 
acquisition events, and requirements and instances of a system. 
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Scope of Acquisition Project 


External Events 


Acquisition^Actlvity 



Requirements 



internal Events 


System 


Figure 2-8: Intuitive Relation of Overall Acquisition Model Elements 


The relations developed in Section 2.2 on page 9 are indicated in the above figure. 
For example, there are relations between external events and acquisition activi¬ 
ties. Note also the relation among different acquisition activities is illustrated in 
Figure 2-8. The structure presented in Figure 2-8 is static in nature, and does not 
show the dynamics associated with the framework. 

A summary of the framework from a mathematical perspective may be found in 
Appendix A on page 77. There we group together the various mathematical as¬ 
pects of the framework. 

We should reiterate our interest in developing the framework specification and the 
question of scope; that is, what amount of detail does one include in the frame¬ 
work, as opposed to a model based on that framework? Later, in Section 5 on page 
49, we will address possible extensions that could be incorporated in the frame¬ 
work. However, at this point we believe the framework satisfies the proper balance 
in terms of its ability to express (and later refine) acquisition concepts and the 
need for additional detail that is required for treatment of a particular acquisition 
model based on the framework. 
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3 An Example: The Waterfall Model 


To provide an illustration of the application of this formal approach, we will con¬ 
sider how a (pure) waterfall development model can be specified. Originally spec¬ 
ified by Royce [6], this model was a mainstay of systems development for many 
years. It has fallen out of favor in recent years, yet is still applied in the context of 
other, more recently developed, acquisition models. In the following we will devel¬ 
op a specification of the waterfall model in the context of the acquisition frame¬ 
work. Some extensions to the waterfall model specification, based on extensions to 
the framework, are described in Appendix D. 

3.1 Basic Specification Elements 

Activities 

The waterfall model [6] is characterized by a set of activities. Its simplest repre¬ 
sentation is shown in Figure 3-1. 



Figure 3-1: Basic Representation of Waterfall Model 
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The choice of presentation in Figure 3-1 is meant to indicate, in its simplest case, 
that the activities are performed in the order shown; hence the term waterfall. The 
arrows shown in Figure 3-1 represent relations between the indicated activities. 

The set of activities shown in Figure 3-1 may be represented in the framework as 
follows: 


Acq_Activities; {System_Requirements_Definition, Software_Requirements_Definition, 

Analysis, Program_Design, Coding, Testing, Operation} ( 3 . 1 ) 

Note that we do not include a subscript [t] on the above. The lack of the subscript 
[tl means that the data object is static, which is the case for the activities defined 
for the waterfall model. 

Events 

The second aspect of the framework is the specification of events. The first group 
of events are those that are internal to the scope of the project. For the waterfall 
model, there are items described that we will interpret as events. These are re¬ 
views defined in the context of interaction with the customer, and we can declare 
them as 

Preliminary_Software_Review, Critical_Software_Review, Final_Software_Acceptance_Review: 
INTERNAL_EVENT 

IntemaLEvents: {Preliminary_Software_Review, Critical_Software_Review, 

Final_Software_Acceptance_Review} (3 2 ) 

The second group of events are those that are external to the scope of the project. 
In the case of the pure waterfall model there are no such external events; this con¬ 
straint is specified by 

#Extemal_Events = 0 

The fact that there are no external events indicates the development does not in¬ 
volve external factors, such as the use of COTS products. 

Requirements 

In terms of requirements, we introduce the following: 
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[REQUIREMENT] 


Requirements: {REQUIREMENT} 

NUMBER_REQUIREMENTS: Number 
#Requirements > 0 

#Requirements = NUMBER_REQUIREMENTS 

The preceding specifies a finite set of requirements whose number is defined by 
the constant NUMBER_REQUIREMENTS. It is important to note that the number of 
requirements is assumed constant. This is in keeping with the assumption of the 
waterfall model, in that there is a fixed set of requirements that are then used to 
develop the system. This further implies that, in the development of operations 
that might be performed on requirements, that one cannot either add or delete a 
requirement. Hence, such operations are not necessary in the waterfall model, al¬ 
though they remain useful in the context of a framework. 

System 

We specify the system as follows: 

[SYSTEM] 

System: [SYSTEM] 

#System = 1 

The above declares that there is only one instance of the system. In recognition 
that the system needs to be maintained, we could specify a set of system instances 
where a given instance of a system is determined by the changes that it incorpo¬ 
rates during maintenance. We shall not take this approach however, because it 
does not lend anything of interest to the model. Furthermore, recall that the em¬ 
phasis on the specification of the waterfall model in [6] was development, and we 
continue that emphasis here. 

Relations Among Activities 

As for the relations among the activities, based on Figure 3-1 one might assume 
that the relations should be defined for only “nearest neighbor” activities. In other 
words, there would be a relation defined between Program Design and Coding, but 
not a relation between Software Requirements Definition and Coding. However, 
the representation shown in Figure 3-1 is the currently popular rendition of the 
waterfall model and does not account for its original specification. In particular, 
the original specification admitted not only “nearest neighbor” relations, but rec¬ 
ognized the necessity for other relations among activities. The basic specification 
of a relation among activities applies here, that is 
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Activity_ReIation: Activities <.> Activities 

3 aj. Uj 6 Activities 

• Activity_Relation (a^ aj) 

(3.3) 


The preceding specifies that every activity is related to every other activity except 
itself Another way to represent relations, whether that defined above or in gener¬ 
al, is to use a matrix representation of the relation. In this case, we would have 


0 1111 
10 111 
110 11 
1110 1 
11110 
11111 


1 

1 

1 

1 

1 

0 


Figure 3-2: Matrix Representation of Activity Relations in the Waterfall Model 

It is assumed that the rows and columns in Figure 3-2 are ordered in correspon¬ 
dence with the activities declared in Eq. (3.1). The value unity denotes a relation 
exists between the indicated activities, and the value zero means there is no rela¬ 
tion specified. 


Relations Among Events and Activities 

The second type of relation in the framework is that between events and activities. 
In terms of reference [6] the relation can be declared as 


Project_Review: Intemal_Events —> Acq_Activities 
3 ejS IntemaLEvents, aj 6 Acq_Activities 
• Project_Review (Cj aj) 


(3.4) 


The character of the relation in Eq. (3.4) is one-to-one: each internal event must 
relate to some activity, but not all activities must be related to an event. 
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The internal events declared in Eq. (3.2) are related to certain activities as dis¬ 
cussed in [6]. In particular, the following relations for project reviews are de¬ 
scribed: 

Project_Review (Preliminary _Software_Review, Preliminary _Program_Design) (3.5) 

Project_Review (Critical_Software_Review, Coding) (3.6) 

Project_Review (Final_Software_Acceptance_Review) (3.7) 

For example, the first relation indicates a relation between an internal event (the 
preliminary software review) and its related activity (preliminary program de¬ 
sign). 

Because there are no external events associated with the waterfall model, there 
are no such relations that we need to consider. 

3.2 Predicates 

In Section 2.1.1 on page 5 we defined predicates for activities that are part of the 
framework. For example, we provided predicates to add, modify, or delete an ac¬ 
quisition activity. In the case of the waterfall model, such predicates are not nec¬ 
essary. The reason is that the activities are pre-defined, hence there is no need to 
define operations to change them. 

For internal events, the framework specification accounts for predicates that allow 
us to add or modify an internal event. Again, because the internal events are pre¬ 
defined in the waterfall model, it is not necessary to define predicates that perform 
such operations. However, two predicates that may be useful in the specification 
of the waterfall model are the following: 

Internal_Event_Occurred (e: INTERNAL_EVENT; t) —» Boolean 

Generate_Internal_Eveiit (e: INTERNAL_EVENT; t) Boolean 

|=> Internal_Event_Occurred (e: INTERNAL_EVENT; t) (3.8) 

For example, using the above predicates it may be possible to indicate that when 
some activity completes, a certain internal event is started. 

Because the waterfall model does not include external events, it is not necessary 
to define predicates that deal with external events. 

For requirements it will be useful to carry over the following predicates from the 
framework specification: 
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Modify_Requirement (rj: REQUIREMENT; t) —> Boolean 
Requirement_Satisried (rj: REQUIREMENT; t) -> Boolean 


(3.9) 


(3.10) 

Although it is assumed that the requirements on the system are known at the out¬ 
set of the project, we need to include a predicate that allows us to modify a require¬ 
ment. It was recognized that there may be a need to go back and modify an initial 
requirement. However, we have not included predicates to create or delete a re¬ 
quirement because their number is assumed fixed. 

Finally, for the specification of predicates related to the system, since there is only 
one instance of the system, we need not define predicates that relate to various 
system considerations. 

The preceding discussion of predicates in the context of the waterfall model has 
turned out to be quite simple and straightforward. The reason for this is because 
so many aspects of the model are based on inherently simple considerations. For 
example, a fixed set of requirements and only one instance of the system is quite 
easy to deal with. 

3.3 Timing Properties 

To begin a discussion of the timing properties associated with the waterfall model, 
we define the times when an implementation of the model starts and stops: 

^tart’ ^top- Time 

We begin a specification of the timing properties of the waterfall model by carrying 
over the definitions to initiate and complete an acquisition activity. 

Initiate_Acquisition_Activity (aj: ACTIVITY; t) —> Boolean 

(3.11) 

Terminate_Acquisition_Activity (aj: ACTIVITY; t) -4 Boolean 
3 t' < t • Iiiitiate_Acquisition_Activity (aj: ACTIVITY; t ) 

^ — ^tart 

*-*stop (3.12) 

Note the pre-conditions placed on the above equations. The operation to initiate an 
acquisition activity requires that the time at which the activity is initiated must 
be later than the time when the project started. Similarly, the time at which an 
activity terminates must be earlier than the time at which the project completes. 
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To specify the initiation of a waterfall development, we require that the first activ¬ 
ity performed is that associated with system requirements. In other words, at a 
time equal to tson the system requirements activity must be initiated. Mathemati¬ 
cally, this can be specified as: 

Initiate_Acquisition_Activity (System_Requirements_Defmition; tstan) -> Boolean 

Given that the model implementation is initiated, the permitted activities that 
may later be formed are those activities that are related to the activity just com¬ 
pleted. It is through the coupling of activities, specified by the relation defined in 
Eq. (3.3), that defines the activities that can be performed. This requirement can 
be specified as follows: 

y t G (tstart’ ^stop) * 

Terniinate_Acquisition_Activity (Hj: ACTIVITY; t) 

=> 

Initiate_Acquisition_Activity (aj: ACTIVITY; t) 

• Activity_Relatton (a; aj) 

aj^taj (3.13) 

Hence, when some activity terminates, the next activity that may be performed is 
one such that it is related to the activity that completed. This is a general form of 
constraint on the execution characteristics associated with a model. In the case of 
the waterfall model, however, once an activity terminates, any other activity can 
be performed. The reason for this is because the relation between acquisition ac¬ 
tivities is that every activity is related to every other activity (except itself). Al¬ 
though most diagrams representing the waterfall model only show activities 
coupled in a nearest-neighbor fashion, as shown in Figure 3-1, the specification of 
the model in [6] is more general. 

An interesting question is: When does the implementation of the waterfall model 
end? On the one hand, one could say “never” because a system goes into operation 
and maintenance after it is developed! In the definition of activities for the water¬ 
fall model, the last two activities are associated with testing and operation. We 
will assume that the implementation of the model ends when both of the following 
two requirements are met: 

• all requirements are satisfied 

• the activity of operation begins 

The framework includes an operation that specifies that a given requirement is 
satisfied (see Eq. (2.23) on page 21). To specify that all requirements are satisfied 
we promote the operation that a given requirement is satisfied over the set that 
includes all the requirements. We can introduce an expression for this case as fol¬ 
lows: 
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AII_Requirements_Satisfied (t*) -> Boolean 

K 

3 t* • 

V Fj G Requirements • 

Requirement.Satisfied (rj: REQUIREMENT; t) 


In other words, the above states that there is a time t* when every requirement 
has been satisfied. 

We may now use the result in Eq. (3.14) to specify the condition that an implemen¬ 
tation of the waterfall model is complete. We have: 

WaterfaIl_Model_Complete (t*) ^ Boolean 

All_Requirements_Satisfied (t*) 

Initiate_Acquisition_Activity (Operation; t*) 

(3.15) 

As indicated earlier, other interpretations of what it means for an implementation 
ot a model to be complete can be provided. It could be the first time that all require- 
ments associated with the system are satisfied, as was the choice represented in 
Eq. (3.15). One could refine the model to account for deployment of a system and 
assume that the time of deployment is when the model is complete. Or, yet another 
choice would be to define the completion time as when the system is retired. 

Fron^he preceding we have specified the timing properties associated with the 
waterfall model. An interesting question is to address the sequence of activities 
that are performed as part of a waterfall acquisition. We will not provide the math¬ 
ematics of this (although it is simple to do so). Instead, in Table 3-1 we show three 
possible sequences of activities for a waterfall model. 

The first column of Table 3-1 represents the basic (ideal) model presented in Fig¬ 
ure 3-1 The second column shows activities that include the iteration between 
some of the nearest-neighbor activities. For example, after performing the design, 
^mg, and test, it may be necessary to go back and perform some coding activity! 
The last column of Table 3-1 shows a more general case where activities may be 
perfomed in an arbitrary order. After performing the activities in the basic ap- 
proach, after testing it may be necessary to go back to the software requirements 
definition nnd then start the sequence over again. 


A specification of a sequence of activities is known as a trace. 
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General 


Basic Nearest Neighbor 


1 

System Requirements 
Definition 

System Requirements 
Definition 

System Requirements 
Definition 

2 

Software Requirements 
Definition 

Software Requirements 
Definition 

Software Requirements 
Definition 

3 

Analysis 

Analysis 

Analysis 

4 

Program Design 

Program Design 

Program Design 

5 

Coding 

Analysis 

Coding 

6 

Testing 

Program Design 

Testing 

7 

Operation 

Coding 

Software Requirements 
Definition 

8 


Testing 

Analysis 

9 


Coding 

Program Design 

10 



Coding 


Table 3-1: Valid Activity Sequences in the Waterfall Model 


Finally, we consider the timing properties of internal events. By defining the rela¬ 
tion between an internal event and some activity as we did in Eq. (3.4), we know 
which events are associated with a given activity. We now require that the inter¬ 
nal event occurs at some time during the execution of its associated activity. This 
can be specified as 

V a; e Acq_Activities • 

Project_Review (e; _ Oj) 

3 t* e Duration {Execute_Acquisitioii_Activity (a;: ACTIVITY; t, t')} • 
Internal_Event_Occurred (cj, aj) 

The above simply states that for every activity that has an associated event, the 
event occurs at some time during the execution of that activity. No further require¬ 
ment is placed on the actual time at which the event occurs during the activity. 


The function of Duration is a projection operator that extracts the times associated with the 
predicate on which it operates. This is a built-in function provided by the language Nestor. 
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3.4 Completeness Considerations 

The specification of the framework contains an important discussion about the 
completeness criteria associated with a particular model. A brief summary of the 
completeness criteria and an index to where they are discussed for the waterfall 
model is provided in Table 3-2. 


Topic 

Section I 

Execution of activities is well specified 

3.4.1 

Treatment of external events 

3.4.2 

Treatment of internal events 

3.4.3 

All requirements satisfied 

3.4.4 


Table 3-2: Completeness Considerations for Waterfall Model 
3.4.1 Execution of Activities Is Well Specified 

The criterion of well specified means that no activity begins at a time before the 
model starts, and no activity ends after the model completes. This is described in 
connection with Eq. (2.37) on page 28. The criteria for well-specified for the water¬ 
fall model are expressed as the pre-conditions associated with Eqs. (3.11) and 


3.4.2 Treatment of External Events 

It is easy to handle this criterion for the waterfall model: The model does not admit 
external events. Hence, this requirement does not apply. 

3.4.3 Treatment of Internal Events 

The waterfall model only specified three internal events, namely preliminary soft¬ 
ware review, critical software review, and final software acceptance review. The 
completeness requirement for internal events, as expressed by Eq. (2.37) on page 
28, is that every internal event must be related to some acquisition activity. This 
criterion is satisfied by Eq. (3.4) and following. 

3.4.4 All Requirements Satisfied 

The last completeness criterion is that all requirements must be satisfied. This 
was specified in Eq. (3.14) on page 40. Furthermore, the specification that all re¬ 
quirements were satisfied was used as part of the pre-condition to the specification 
that the model is complete. 
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3.5 Reasoning About the Specification 

One of the advantages of a formal, mathematical approach is that it lends itself to 
reasoning in a precise manner. This is t 5 ^ically described under the ability to 
state, and complete, proofs about some aspect of a specification. Our intent here is 
not to go into details about application of proof-theoretic techniques about the 
specification of the waterfall model. However, let us consider some small examples 
that deal with reasoning about the specification. 

Can the same activity be executed immediately after it has terminated? 
No. The reason is evident from Eq. (3.13) and the restriction that a^ aj. An activ¬ 
ity can be initiated only if it is related to another activity, and an activity is not 
defined as relating to itself. 

Must every activity be executed at most one time? No. The specification of 
the waterfall model does not make any such restriction. An implementation of the 
specification of the waterfall model may, however, exhibit such behavior. 

If an implementation of the model completes, what happens if a require¬ 
ment is later changed? The specification is silent on this point. That is, there is 
an assumption that all the requirements are known at the start of the model and 
thereafter constant. There are not operations in the specificaiton of the waterfall 
model to add or delete a requirement, although there is an operation that allows a 
requirement to be modified. 

What happens if an acquisition activity is suspended; can there be times 
when no activity is in progress? Again, the specification is silent on this point. 
While the general specification of the framework does provide operations for an ac¬ 
tivity to suspend and resume, those operations are not incorporated in the specifi¬ 
cation of the waterfall model. The reason is that the specification is silent with 
respect to this question. 

The above illustrates simple cases where one can pose a question of the specifica¬ 
tion and obtain a response that can be substantiated mathematically. It is this 
point—the ability to formally reason over the domain of a specification—^that is so 
valuable to a formal approach. 

3.6 Summary 

There are a number of points that should be noted as a summary of a formal spec¬ 
ification of a waterfall model. Two key points include the following: 

• The formal specification serves to validate the utility of the 
framework. The specification of activities, events, and their 
relations, as well as execution character, has allowed a precise 


3 An Example; The Waterfall Model 

3.5 Reasoning About the Specification 




specification of the waterfall model. Note that not all of the 
framework capabilities were required to specify the waterfall 
model. 

• The development of the formal specification has required us to 
carefully define the model with the precision required of a 
mathematical approach. This is one of the well-known benefits of a 
formal approach. 

We believe that the formal approach taken here can also be applied to other mod¬ 
els that are used for an acquisition. Some of these will be noted in the following 
section. If one can develop a formal specification of an acquisition model based on 
the framework developed in Section 2, with possible extensions, it allows one to 
compare the different acquisition models in a more enlightened manner. This, in 
turn, helps one gain deeper understanding of an acquisition model. 
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3.6 Summary 



4 Discussion 


The framework that has been developed in this report is purposefully general in 
nature. The intent is that the framework can serve as the basis for the develop¬ 
ment of particular acquisition models, which are instances of this framework. This 
approach is indicated in the following figure: 



Figure 4-1: Acquisition Models 

Figure 4-1 shows some possible acquisition models that could be specified in terms 
of the acquisition framework. We recognize and expect that it may be necessary to 
add additional details to the basic framework specification as one applies the 
framework to a particular model. The models indicated here are: 

• waterfall model: the well-known model based on the work of Royce 
[6], which was illustrated in Section 3 

• spiral model: another well-known model, based on the work of 
Boehm [1] 

• incremental models, also sometimes considered to be evolutionary 
in nature 

• other possible acquisition models 

Although the above represent some of the well-known models that are discussed 
today, they can be embellished in different ways. For example, if one seeks to per¬ 
form an acquisition that places heavy emphasis on the use of open systems and 
COTS products, this introduces additional considerations that must be accounted 
for in the model; see [5] for further discussion of this point. 

A simplified comparison of the above models, in terms of concepts employed in the 
framework developed here, is summarized in Table 4-1. 
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Spiral 

Incremental 

Requirements 

Assumed known at 
start of project 

Developed as the 
project progresses 
with each iteration 
of the spiral 

Assumed known at 
start of project 

Activities 

System Require¬ 
ments, Software 
Requirements, 
Analysis, Program 
Design, Coding, 
Testing, Operation 

Top level specifica¬ 
tion includes plan¬ 
ning, risk 

management, engi¬ 
neering, and cus¬ 
tomer evaluation 

Various choices 
possible: e.g., 
those associated 
with the waterfall 
model 

Events 

Preliminary soft¬ 
ware review, criti¬ 
cal software review, 
final software 
acceptance review 

Various choices 
possible 

Various choices 
possible 

Relations 

Arbitrary coupling 
between activities 
permitted, but 
mainly expected to 
be between nearest 
neighbors 

Coupling between 
each activity in a 
cycle and end of 
one cycle to next 
cycle 

Various, based on 
activities chosen 

Timing Prop¬ 
erties 

Activities per¬ 
formed serially 

Activities per¬ 
formed serially 
within repetitive 
cycles 

Activities per¬ 
formed serially: 
each increment 
adds more func¬ 
tionality (i.e., satis¬ 
fied requirements) 

System 

Instances 

Focus on only one 
instance of the sys¬ 
tem 

Multiple instances 
determined during 
execution of acqui¬ 
sition model 

Pre-planned multi¬ 
ple system 
instances 


Table 4-1; Comparing Different Acquisition Models 


We emphasize the simplified view presented in the above table. It is more illustra- 
tive of the characteristics of these models, as opposed to details associated with 
them. No doubt proponents of one model or another may cry foul at the simplifica¬ 
tion. In response we would welcome well-specified definitions of these models in 
the context of the framework defined here. 
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One of the primary differentiators of the models shown in Table 4-1 is the manner 
in which the requirements are satisfied by an instance of a system over time. In 
the waterfall model, for example, all requirements are assumed known at the out¬ 
set, and one proceeds to develop the (hopefully) final instance of the system. In 
contrast, a spiral development approach adds requirements over time that are im¬ 
plemented in different instances of the system over time, leading to a desired final 
instance of the system. 

Although the approach to satisfying requirements as part of a system acquisition 
is a differentiating characteristic, there are others that deserve attention. We 
would suggest that the increased emphasis on how open standards and COTS 
products are addressed in an acquisition is another key characteristic of an acqui¬ 
sition model. In particular, consideration of standards and their relation to COTS 
products leads one to deal with models where external events (such as the upgrade 
of a COTS product) are crucial to the acquisition. Further discussion of open stan¬ 
dards, COTS-based acquisition may be found in [5]. 

Each of the above models is comprised of different activities, events, and relations 
among the activities, including their operational semantics. We believe there 
would be significant value in the formal specification of the above models. Being 
able to compare the models in a formal context adds value not oiily understand¬ 
ing the model itself, but how one model relates to other models.^^ Furthermore, 
the development of a robust specification could be used to help manage an acqui¬ 
sition project, and we would expect a work breakdown structure could be derived 
from a formal model. 

It is out of the scope of this report to develop a formal specification for all the mod¬ 
els listed above. We would hope, however, that this framework can be applied to 
various acquisition models, which are often only loosely stated. The existence of a 
formally specified acquisition model, such as a spiral model, for example, would al¬ 
low one to then speak of a theory of spiral acquisition. It is through the application 
of a formal approach tha,t we are allowed not only to specify but to reason about 
various acquisition models. 


To illustrate some of the confusion that exists, we recently reviewed a document consisting 
of over 3,000 supposedly completed requirements for a system. That was fine, until the 
claim was made that this was going to be a spiral acquisition! 
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5 Possible Extensions to the Framework 


Our goal in specif 5 dng the framework in Section 2 was to take a minimalist ap¬ 
proach. That is, we wanted to limit the scope of the specification with respect to 
the amount of detail present. There are other possible topics that could be included 
in the framework, although we have chosen not to take that approach. One of the 
basic problems in specifying any type of framework is to know when to stop! Clear¬ 
ly, there are other topics that could be relevant for a model specification based on 
the framework defined here. In this section we will illustrate some other possible 
considerations. 

5.1 Elaboration of Acquisition Activities and Events 

The framework does not specify any particular set of acquisition activities. The 
reason is that the choice of activities is deemed relevant to a particular model 
based on the framework. Although we could have attempted to declare a particular 
set of activities, we realize there is always the case where model developers will 
require perhaps different activities. 

Furthermore, we have not explicitly specified that an acquisition activity could be 
divided into a set of other activities. For example, consider an activity Code Con¬ 
struction. We could envision that this activity be further refined to include more 
detailed activities such as Code Development, Code Inspection, Code Guideline De¬ 
velopment, and so on. There is nothing in the framework that prevents an activity 
from being defined as a subset of other activities. If this approach is required, it 
can be easily incorporated in a particular model. 

In a similar manner, if deemed necessary, one could partition the acquisition ac¬ 
tivities into two subsets. One subset would be used to represent technical activi¬ 
ties, while the other would be for management activities. We would then define 

Technical_ActivitieS[(]: {ACTIVITY} 

Management_Activities [[j: {ACTIVITY} 

Technical_ActivitieS[t] n Management_ActivitieS[t] = 0 

The last line requires that the sets of technical and management activities have 
no activity in common. 

One reason for treating management and technical activities separately is to rec¬ 
ognize their separate importance. Taking this view allows for a “divide and con¬ 
quer” approach. Additionally, we note that the technical activities are typically of 
bounded duration, while the management activities are performed over the entire¬ 
ty of a project life cycle. 
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The preceding discussion also applies to the events that are included in the frame¬ 
work. That is, we do not feel it is appropriate to attempt to specify each possible 
event that could be included in the framework. 

We do believe, however, that the separation of events into internal and external 
events is fundamental and does belong in the framework (as well as the relations 
between events and activities). One of the characteristics of current acquisition 
practice is the need to deal with standards and commercial off-the-shelf (COTS) 
products. There are events associated with each of these activities; for example, 
the revision to some COTS product would be represented as an external event. 
Further discussion of standards-based COTS acquisition can be found in [5]. 

5.2 Requirements 

The framework postulates a finite set of requirements and specifies that those re¬ 
quirements are related to one (or possibly more) instances of a system. There are 
a number of operations that can be performed on requirements that are not part 
of the core framework specification. For example, one could define the following 
operations: 

Requirement_Correct (r- REQUIREMENT; t) ^ Boolean 

Requirement_Self_Consistent (t;: REQUIREMENT; t) ^ Boolean 

Requirements_Consistent (rj, rj: REQUIREMENT; t) -» Boolean 

We did not include the above predicates in the core framework specification be¬ 
cause such predicates are more focused toward a specification of an acquisition 
model. Recall that the main concern in specifying the framework is to include 
those operations and data structures that are useful in the characterization of dif¬ 
ferent acquisition models, and for which one can compare different models. In that 

sense, the operations defined above do not appear to warrant consideration in the 
basic framework. 

We have assumed a set of requirements without dealing with them in any further 
detail. One area of possible consideration deals with requirements semantics. For 
example, one could require that the semantics of a requirement be unique with re¬ 
spect to other requirements. The formalism applied here permits such a specifica¬ 
tion, and while perhaps of general interest, we chose not to include it.^^ 


The language Nestor includes some powerful operations for dealing with semantics of 
predicates and associated state data. 
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5.3 Participants 

Acquisition is performed in a context that has multiple participants, each possibly 
assuming different roles. For example, one could consider 

• end-user 

• developer 

• project manager 
Another choice might be to consider 

• end-user 

• project manager 

• developer agent 

• prime contractor 

• sub-contractor 

In the latter case, the roles of prime contractor and sub-contractor are similar to 
that of the developer, which appears in the first set of alternatives. Furthermore, 
it is also possible to refine the roles of the project manager. For example, one could 
have a test manager, budget analyst, and so on. 

Recognizing the many possible choices to delineate various roles on a project, we 
have chosen to remain silent about these roles in the specification of the frame¬ 
work. Of course, a particular set of roles could be included in the development of a 
particular acquisition model. 

Another reason for not including the roles is based on a separation principle of 
what versus who. Our prime concern is what activities are perfornaed, rather than 
who performs that activity. While we recognize the possibility of including a par¬ 
ticular role, we believe that is outside the scope of the core framework. 

The following provides some guidance, if one were interested in specifying partic¬ 
ipants in a specification of an acquisition model. We would begin by declaring a 
free type to represent a participant, namely: 

[PARTICIPANT] 

Next, we need to identify who the particular participants are. For example, from 
the perspective of a project office that is responsible for management of the acqui¬ 
sition, we could include the following: 
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Project_Manager, System_Engineering, Software_Engineering. Systeni_Test: PARTICPANT 


Project_Management_Staff[t]: {Project_Manager, System_Engineering, Software_Engineering, 
System_Test} 

From the developer perspective, we might wish to define the following set of par¬ 
ticipants: 

Developer_Manager, DeveIoper_System_Engineering: PARTICIPANT 

Given the basic set of participants, there are now operations that we can perform 
on these basic declarations. For example, suppose we wanted to specify a joint In¬ 
tegrated Project Team, whose members were acquisition project managers and the 
manager of the developer effort. We could do this in the following manner: 

Joint_Manageinent_Team[j]: {Project_Manager, Developer_Manager} 

Also, for purposes of illustration, we can create a joint team for system engineer- 
mg, namely: 

Joint_System_Engineering_Team[tj: {System_Engineering, Developer_System_Engineering} 

Hence, given the basic type declaration for a participant, we can declare and com¬ 
bine them in ways that are appropriate to the particular concerns of the model. For 
example, suppose we were interested in including an operation in the acquisition 
model that specified the approval of some acquisition activity. This can be repre¬ 
sented as a relation between participants and activities, as shown in Figure 5-1. 


Participant Activity 



Figure 5-1: Development of Approval Relation 


There are different ways in which the approval process can be modeled. For exam' 
pie, suppose we have the following model: 

• Every activity must have at least one participant who can approve 
the activity (the relation is total over the range). 
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• A given participant may approve more than one activity (the 
relation is many-to). 

• A given activity may be approved by only one participant (the 
relation is to-one). 

• Not all participants need to have approval authority for an activity 
(the relation is partial over the domain). 

The specification of a relation satisfying the characteristics above is as follows: 

Approval_Authority: Participants^t] <"l-Activities^tj 

3 Pi € ParticipantSft], aj e ActivitieSfy • 

Appro val_Authority (Pi, aj) (5 1) 

Given the specification of the above relation, we can declare those ordered pairs 
that are members of the relation. For example, suppose we were concerned with 
activities of requirements management and system development. The relevant re¬ 
lations could be declared as: 

ApprovaI_Authority (Project_Manager, Requirements_Management) 

Approval_Authority (System_Engineering, System_Development) 

Approval_Authority (Developer_Systein_Engineering, System_Development) (5-2) 

Note that the above permits two different participants to have approval authority 
for the system development activity, namely either a project or developer agent 
who is responsible for system engineering. It does not, however, permit^the overall 
project manager to have approval authority for system development. 

We may use the above notion of approval authority to refine the specification of 
what it means to initiate some acquisition activity. In the development of the 
framework we included an operation that specified the initiation of some acquisi¬ 
tion activity (see Eq. (2.29) on page 23). We include the concept of approval author¬ 
ity as a pre-condition to initiating some activity; in other words, an activity cannot 
begin until there is a participant who has approval authority for the activity. 
Hence, we modify Eq. (2.29) as follows: 

Initiate_Acquisition_Activity (aj: ACTIVITY; t) Boolean 

3 Pi e ParticipantSft] • 

ApprovaLAuthority (pj ,aj) (5.3) 


The degree to which this choice is appropriate will not be further speculated upon here! 
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Hence, Eq. (5.3) means that an acquisition activity cannot be initiated unless there 
IS a participant who has approval authority for that particular activity. This is a 
reasonable approach to dealing with approval requirements for acquisition activi¬ 
ties, although we recogjnize that other approaches are possible. For example, the 
project manager could have a “veto” power and ability to approve any acquisition 
process. If this is the desired approach, however, the specification must account for 
the application of a veto power by the acquisition manager. 

5.4 Artifacts 

As part of an acquisition there are many artifacts that are developed or used. We 
use the term artifact to denote some document or product that is developed or used 
m an acquisition. Examples of artifacts can include 

• software development plan 

• contract 

• software requirements document 

• standard 

• COTS product^® 

• budget 

Clearly, as indicated above, artifacts can be of different types and serve different 

purposes. Furthermore, artifacts can be used in different ways in the same acqui¬ 
sition. 

We do not include artifacts in the specification of the framework. Our reason is 
that a specification of artifacts, relations among them, and predicates associated 
with their use is not fundamental in order to compare different acquisition models 
that can be created as an instance of the framework. That is, many different mod¬ 
els can be used that employ artifacts, but the manner in which the artifacts are 
used, we believe, is not fundamental to the ability to characterize key differences 


It may be more likely that COTS products, as well as standards, are treated in an indepen¬ 
dent manner; i.e., not as a subset of general artifacts. The choice to be made relates to the 

importance one wishes to attribute to standards and COTS products in an acquisition mod- 
©1. 
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1 1 

among different acquisition models/ 

It would be possible to include some general operations on artifacts in the frame¬ 
work. Toward this end, we could specify a data type 

[ARTIFACT] 

We could then specify a set of artifacts and perform operations on a general arti¬ 
fact like create_artifact, modify_artifact, and so on. A similar approach was taken 
in the way we dealt with requirements, for example (see Section 2.1.3 on page 7). 

However, consider the case where one is interested in a specification of an acqui¬ 
sition model that places emphasis on the use of COTS products. While a COTS 
product can be viewed as a type of artifact, assume that we wish to treat it as a 
first-class object. In this case, we make the declaration: 

[COTS_PRODUCT] 

We can also declare a set whose elements are all COTS products (as opposed to 
also including artifacts of other types) as 

COTS_ProductS[t]: {COTS_PRODUCT} 

Taking the above approach allows us to concentrate on aspects of the acquisition 
model that are specific to the use of COTS products. For example, some predicates 
that we may find useful in describing an acquisition model that emphasizes COTS 
products include^® 

New_COTS_Product_AvailabIe (cj: COTS_PRODUCT; t) Boolean 
COTS_Product_Evaluated (cj: COTS_PRODUCT; t) --4 Boolean 
COTS_Product_Acceptable (q: COTS_PRODUCT; t) -4 Boolean 


One could make the same argument for requirements. However, we note the following im¬ 
portant point: The manner in which a set of requirements is mapped onto different builds is 
indeed a key characteristic that allows comparison among different acquisition models. For 
example, a key difference between a waterfall model and an incremental model is the man¬ 
ner in which the requirements are mapped onto different instances of a system. Hence, re¬ 
quirements must be included in the framework in order to make the comparison among dif¬ 
ferent acquisition models. 

Further consideration of acquisition models that include COTS products can be found in [5]. 
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COTS_Product_Upgraded (c- COTS_PRODUCT; t) Boolean 

predicates defined above represent only a small sample of what could be spec¬ 
ified in a particular acquisition model. The important point is that the framework 
provides the necessary constructs to develop an approach for dealing with artifacts 
appropriate to a given acquisition model. 

5.5 Entrance and Exit Criteria 

There are cases where an acquisition includes a specified set of entrance and exit 
criteria. These criteria represent conditions that must be satisfied in order to ei¬ 
ther initiate or complete a specified activity, respectively. The following are exam¬ 
ples of such criteria: 

• There must be no high-priority defects in any software component 
prior to entering system testing. 

• There must be no outstanding change requests against a 
requirements document in order to complete a requirements 
specification activity. 

Specification and operations on entrance and exit criteria have not been included 
as part of the framework. This choice was made for two reasons: 

1. In many cases the entrance and exit criteria are rather trivial. For exam¬ 
ple, it is often the case that the entrance criteria for an activity are asso¬ 
ciated with the completion of the previous activity. Similarly, the exit cri¬ 
teria for an activity may be principally associated with the completion of 
the activity. To include material at a lower level of specification was 
deemed unsuitable in the framework. 

2. The framework already contains implicit mechanisms to incorporate 
entrance and exit criteria. For example, the predicate to delete an 
acquisition activity was defined by Eq. (2.12) on page 17: 

DeIete_Activity (a^: ACTIVITY; t') Boolean 
\=> 

Acq_ActivitieS[t'] = Acq_Activitiesr,n \ {aj} 

t’>t 

Note that there is no pre-condition associated with the operation that 
deletes an acquisition activity. If one wanted to account for entrance 
criteria in the above predicate, the natural approach would be to add a 
pre-condition that specifies that the desired criteria must be satisfied.^® 

Thus, the framework already provides mechanisms by which entrance 


For example, one might reasonably argue that an acquisition activity should not be deleted 
if the activity is in progress. 
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and 6xit critaria may be included as part of a refinement of the framework 
in the context of a particular model. 

We recognize, however, that there are indeed cases where treatment of entrance 
and exit criteria is important. Some examples of such cases were illustrated above. 
To specify such criteria in the framework, we introduce a criterion and then define 
relevant sets as 

[CRITERION] 

Entrance_Criteria|-t]; {CRITERION} 

Exit_Criteria[t]: {CRITERION} 

We could have required that the sets Entrance_Criteria and Exit_Criteria be dis¬ 
joint. However, we believe that in the context of a framework, as opposed to an in¬ 
stance of that framework, such a requirement would be overly constraining. In 
other words, there may be some criteria that are used both as entrance criteria and 
exit criteria. 

It is appropriate to specify the relation between the criteria and acquisition activ¬ 
ities. We assume the following general conditions apply to both entrance criteria 
and exit criteria: 

• Each criterion must be related to at least one activity. 

• A given criterion may apply to more than one activity. 

• Not all activities need have criteria associated with them. 

• A given activity may have multiple criteria. 

A diagram of the relation between criteria and activities that satisfies the above 
conditions is shown in Figure 5-2. 


Criteria Activity 



Figure 5-2: Relation Between Entrance and Exit Criteria and Activities 

The relations between the criteria and acquisition activities, representing the 
above conditions, are: 
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Entrance_Criterion_Activity_ReIation: Entrance_Criteria[t] <—1-> Acq_ActivitieSf,j 
3 Cl G Entrance_Criteria[,], aj G Acq_ActivitieS[(] 

• Entrance_Criterion_Activity_Relation (e, aj) (5 4 ) 

Exit_Criterion_Activity_Relation: Exit_Criteria[t] <—1-> Acq_ActivitieS(t] 

3 ejG Exit_Criteria[t], aj: Acq_ActivitieS[(] 

• Exit_Criterion_Activity_Relation (ej aj) (5 5) 

In the above we have defined a relation for each of the relevant types of criteria 

It is also helpful to introduce some operations on entrance and exit criteria. We 
would like to be able to specify that some criterion is satisfied at a time t. We write 
these in the following manner: 

Entrance_Criterion_Satisfied (e- ENTRANCE.CRITERIA, aj: ACTIVITY; t) Boolean(5.6) 

Exit_Criterion_Satisried (e - EXIT.CRITERIA, aj: ACTIVITY; t) ^ Boolean ( 5 . 7 ) 

To determine whether, for example, some entrance criterion is not satisfied, we 
can simply negate the predicate in Eq. (5.6). ’ 

How can we incorporate the entrance and exit criteria in terms of the basic frame¬ 
work specification developed above? This is a fairly straightforward matter if we 
recognize that these criteria can be considered to be pre-conditions on other pred¬ 
icates. 

For example, to initiate some acquisition activity, we need to include a pre-condi¬ 
tion to the predicate Initiate_Acquisition_Activity defined in Eq. (2.29) on page 
23. l^e statement of the pre-condition is that, in order to initiate an acquisition 
activity, all of the entrance criteria for that activity must be satisfied. We can rep¬ 
resent this requirement as follows: 

Initiate_Acquisition_Activity (aj: ACTIVITY; t) Boolean 

l~^ 

V Cj G Entrance_Criteria • Entrance_Criterion_Activity_ReIation (Cj a ) 

Entrance_Criterion_Satisried (Cj: ENTRANCE_CRITERIA, aj: ACTIVITY; t’) 

* (5.8) 

In a similar manner, we can develop the specification for the exit criteria in terms 
of the termination of an acquisition activity as follows: 


It would be possible to write the relations in Nestohn terms of a generic and then instantiate 
the generic mapping for each case, but we have chosen not to follow that approach. 
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Terininate_Acquisition_Activity (aji ACTIVITY; t) —> Boolean 
1 ^ 

V Cj G Exit_Criteria • Exit_Criterion_Activity_Relation (Cj aj) 

Exit_Criterion_Satisfied (eji EXIT_CRITERIA, aj: ACTIVITY; t') 


Note that if there are no criteria associated with an activity, the above expressions 
are equivalent to those developed earlier. That is, for example, if there are no en¬ 
trance criteria associated with an activity, then Eq. (5.4) is identical to Eq. (2.29). 

As a means of summary, in Figure 5-3 on the next page we present a specification 
for treating entrance and exit criteria as part of the acquisition framework. 

We emphasize that this represents a candidate specification for entrance and exit 
criteria. We believe that it is sufficiently general that it can be the basis for other 
possible refinements Some items of possible interest include the following: 

• If some entrance criteria are satisfied when an acquisition activity 
is initiated, is it necessarily true that the same entrance criteria 
are also satisfied when the activity terminates? 

• Can exit criteria for some activity be changed during the execution 
of that activity? In other words, should it be possible to modify the 
exit criteria? 

• Can an exit criterion be deleted during the execution of its 
associated activity? If so, what should happen? 

• During the execution of some activity, can new entrance criteria be 
added that are related to the activity in progress? 

The above questions illustrate issues that may be worth considering as possible 
extensions to the framework. The questions also apply if one seeks to include en¬ 
trance and exit criteria in the development of an acquisition model. 

5.6 Phases 

In some acquisition approaches one encounters the concept of an acquisition 
phase. Loosely speaking, a phase is a collection of related acquisition activities. 
There are different approaches to specifying a phase. 
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Theory Entrance_Exit_Criteria 

[CRITERION] 

Entrance_Criteria[(]: {CRITERION} 

Exit_Criteriaft]: (CRITERION) 

Entrance_Crlterion_Activity_Relation: Entrance_Criteria[t] — > Acq_ActivitieS[t] 

3 Bj G Entrance_Criteria[t], e Acq_ActivitieS[,] 

• Entrance_Criteria_Activity_ReIation (Cj aj) 

Exit_Criterion_Activity_ReIation: Exit_Criteriaj(j —> Acq_Activitiesj(j 
BcjG Exit_Criteria[,], aj G Acq_ActivitieS[tj 

• Exit_Criterion_Activity_Relation (Cj aj) 

Entrance_Criterion_Satisfied (ej: ENTRANCE_CRITERIA, aj: ACTIVITY) 

—> Boolean 

Exit_Criterion_Satisfied (e,: EXIT.CRITERIA, aji ACTIVITY) ^ Boolean 

Initiate_Acquisition_Activity (aj: ACTIVITY; t) Boolean 
1 “^ 

V Bj G Entrance_Criteria[t] * Entrance_Criterion_Activity_Mapping (ej a ) 
Entrance_Criterion_Satisried (6- ENTRANCE_CRITERIA, ACTIVITY) 

Terminate_Acquisition_Activity (aj: ACTIVITY; t) -> Boolean 

V Bj G Exit_Criteria[t] * Exit_Criterion_Activity_Mapping (cj aj) 

Exit_Criterion_Satisfied (e - EXIT_CRITERIA, aj: ACTIVITY) 

end Entrance_Exit_Criteria 


Figure 5-3: Theory Component for Entrance and Exit Criteria 
5.6.1 Sequential Phases 

One approach to specifying an acquisition phase is to define it as a sequence of ac¬ 
tivities where the activities that comprise the phase are performed serially. To for¬ 
malize this approach to a phase, we begin by defining a phase as 

Phaseftj: sequence {ACTIVITY} 

#Phase > 0 
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We require that the number of activities in the phase must be greater than zero. 
Note that the above definition of a phase does not require that each activity be per¬ 
formed only once. 

We next define the start and end of a phase as follows: 

^tart’ ^stop' Tune 

tstart ^ Time_of [Initiate_Activity (Head(Phase[t]))] 
tstop —> Time_of [Terininate_Activity (TaiKPhase^t]))] 

The start and stop times are obtained from the times when the first and last activ¬ 
ities in the phase are initiated and terminated, respectively.^^ These are obtained 
by applying the function Time_of to a predicate.^^ 

The requirement that only one activity may be performed at a time is specified by 

^ ^ * ^start — t — tstop 

aj e Phascft] • 

Activity_in_Progress (aj; t) (5.10) 

The above expression says that for all times between the start and stop time of a 
phase, there exists only one activity (denoted by the symbol that is in progress 
at any time. 

It is also useful to define the property that an acquisition phase is well defined. By 
this we mean that the end of one activity corresponds to the beginning of the next 
activity. This is specified by the following: 

Vie 1 ... #Phase[t] -1 

Terminate_Acquisition_Activity (af. ACTIVITY) = 

Iiutiate_Acquisition_Activity (aj^ j: ACTIVITY)) (5.11) 

In other words, for every acquisition activity in the sequence from the first to the 
next to last (as indicated by the use of the ellipsis) the termination of one activity 
coincides with the start of the next activity. This implies that there is no “idle 
time” between the end of one activity and the initiation of another activity. 


When an acquisition phase is represented as a sequence, the operations Head and Tail 
return the first and last element in the sequence, respectively. 

22- The function Time_of is a built-in function in the language Nestor. It is technically referred 
to as a temporal projection operator. 
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The preceding approach to an acquisition phase is illustrated graphically in Figure 
5-4. 


Activity-1 -■ 

A 

Activity-2- 


Activity-3- 

t 


Figure 5-4: illustration of an Acquisition Phase 

Figure 5-4 shows three acquisition activities that are performed serially. The ar¬ 
rows between activities denote relations between the indicated activities. The 
starting and stopping times of the phase are also indicated. Figure 5-4 illustrates 
some of the criteria we specified for a serial phase; for example, the end of one ac¬ 
tivity corresponds to the beginning of the next activity. Note however, that the pre¬ 
ceding development does not specify the number of times a given activity can be 
performed in a phase. That is, a particular activity could be performed one time or 
repeated times during an acquisition phase. 

A summary of the formal specification of a sequential phase is shown in Figure 5- 
5 on the next page. 

5.6.2 Other Choices 

The sequential model of a phase is perhaps the most intuitive, but certainly other 
approaches are possible. One would expect a general requirement that there be 
transitive closure of the activities that comprise a phase, regardless of how the ac¬ 
tivities in the phase are executed on some interval. 

One other choice for a specification of a phase is that it consist of a set of related 
activities, as opposed to a sequence of activities. This is tantamount to “a model 
within a model. There is considerable freedom in how such an acquisition phase 
could be specified. Because it can be viewed as a general model, limited only by its 
start and stop of execution time, we shall not discuss this choice any further. Rec- 
ognition of the model in a model context can be used to construct the desired fea¬ 
tures for what is included in a particular phase. It should be clear that a major 
characteristic of the use of phases in an acquisition deals with the timing of when 
activities are performed. Some further discussion concerning timing properties ap¬ 
pears in Section 5.7. 
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Theory Serial_Phase 
[ACTIVITY] 

PhasCf,]: sequence {ACTIVITY} 

#Phase > 0 

^tart’ ^top' Time 

tstart Time_of [Initiate_Activity (Head(Phase[t]))] 

tstop Time_of [Terminate_Activity (TaiKPhase^t]))] 

^ ^ * ^start — I — tstop 
3j aj 6 Phase^t] 

Activity_in_Progress (a,; t) 

Vie I... #Phase[y - 1 

Terminate_Acquisition_Activity (ap ACTIVITY)) = 
Iiutiate_Acquisitioii_Activity (aj^.i; ACTIVITY)) 

end Serial_Phase 


Figure 5-5: Specification of a Serial Phase 

In closing, let us note that it is also possible to specify a relation between entrance 
and exit criteria (discussed in Section 5.5) and various formulations of an acquisi¬ 
tion phase. For example, the material developed in Section 5.5 can be integrated 
with the specification of phases so that one achieves a specification of entrance and 
exit criteria for an acquisition phase. 

5.7 Execution of Acquisition Activities 

One of the differentiators among a set of models is their operational semantics. In 
particular, timing of the performance of various acquisition activities is a signifi¬ 
cant factor. In this section we expand on this topic. Our purpose is to illustrate how 
a fonnal approach can help in the specification of this aspect of an acquisition mod¬ 
el. 

5.7.1 Serial Models 

First, suppose we wanted to define a sequential acquisition model. We can state 
this in the following manner: 
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Ssquential Acquisition Model: An acquisition model is sequential on 
some interval [t, f] iff only one acquisition activity may execute at 
any one time. 

A formal definition of a sequential model can be obtained by considering the fol¬ 
lowing predicate: 

Sequential_Acquisition_Model (t, f) Boolean 
|-» 

V t* G [t, f] 

3i ajG Acq_ActivitieS[(] • 

Execute_Acquisition_Activity (aj: ACTIVITY; t, t*) 

This is stated as a conditional predicate, in that if there exists only one activity 
that may execute at a given time, the model is sequential. 

A possibly useful inquiry function when developing a model is the ability to deter¬ 
mine if two different acquisition activities are performed in a serial manner. This 
would mean that the termination of one activity would coincide with the beginning 
of another activity. Such a function can be written as: 

SeriaLActivities (aj, aj: ACTIVITY) Boolean 

Instant [Terminate_Acquisition_Activity (a;: ACTIVITY; t)] = 
instant [Initiate_Acquisition_Activity (aj; ACTIVITY; t')] 


An example of the application of this acquisition activity serialization is to the 
specification of the traditional waterfall model [6], where some set of activities is 
performed serially. In fact, a formal specification of the waterfall model would 
have a serialization requirement placed on the execution of acquisition activities. 

5.7.2 Parallel Models 

The more interesting case is where parallelism is present in the execution of ac¬ 
quisition activities. To begin, we define two operations that will prove useful 
namely ’ 

Acquisition_Activity_Start (aj: ACTIVITY; t) Time 

=> Instant [Initiate_Acquisition_Activity (aj; ACTIVITY; t)] 

The operation Acquisition_Activity_Start is of type time\ the function instant is 
a projection operator that extracts the value of time for a predicate that has a sin¬ 
gle argument of type Time. Hence, the result expressed above simply provides the 
time some activity started, namely t. 
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In a similar manner we define the time at which an activity stops as 


Acquisition_Activity_Stop (aj: ACTIVITY; t) —> Time 

=> Instant [Terminate_Acquisition_Activity (aj; ACTIVITY; t) 

To develop the specification for parallel execution in an acquisition model, first let 
us define a predicate that indicates that two activities execute in parallel. We do 
this as 

ParalleLActivities (a^ aj: ACTIVITY) -4 Boolean 

V t* 6 [t, t'] • Execute_Acquisition_Activity (a;; ACTIVITY; t, f) 

3 aj G Acq_Activities • 

Initiate_Acquisition_Activity (aj; ACTIVITY; t*) v 

Terminate_Acquisition_Activity (aj; ACTIVITY; t*) (5.12) 

In other words, activities a; and aj are parallel if, during the execution of activity aj, 
activity aj either starts or stops. 

It is possible to distinguish between different t37pes of execution. The first we shall 
denote as closed parallel execution, and the second will be denoted as open parallel 
execution. These are illustrated in Figure 5-6. 



Sequential 


Closed Parallel 


Open Parallel 


Figure 5-6: Types of Activity Execution 

Each panel in Figure 5-6 shows the execution of three h 3 q)othetical acquisition ac¬ 
tivities. Time increases to the right along each line. The left-hand panel of Figure 
5-6 shows the case of sequential execution. 
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5.7.2.1 Closed Parallel Models 


The center panel in Figure 5-6 illustrates the case of closed parallel execution.We 
define this as follows: 


Closed Parallel Execution: An acquisition activity a, exe¬ 
cutes in a closed parallel manner with respect to acquisition 
activity aj iff the execution interval for activity aj is wholly 
contained within the execution interval of activity a,. 

We have introduced the concept of an execution interval in the above definition. 

This is the set of times when an acquisition activity is executing. 

We may develop a predicate to indicate whether two different acquisition activities 

are executed in a closed parallel manner: 


CIosed_ParalleI_Activities (aj, a^: ACTIVITY) —> Boolean 

Acquisition_Activity_Start (a;: ACTIVITY; t) < 
Acquisition_Activity_Start (aj: ACTIVITY; t) 

A 


Acquisition_Activity_Stop (a;; ACTIVITY; t) > 
Acquisition_Activity_Stop (aj; ACTIVITY; t) 

aj^t aj 


(5.13) 


5.7.2.2 Open Parallel Execution 

T^e other case of parallel execution of two acquisition activities is shown in the 
right panel of Figure 5-6. Note that in this case, some activities overlap in (the 
time of) their execution. We define this as 


Open Parallel Execution: An acquisition activity aj executes 
in an open manner with respect to acquisition activity aj iff 
(i) the activities execute in parallel, and (ii) the execution in¬ 
terval for activity aj is not wholly contained within the execu¬ 
tion interval of activity aj. 

We may formally define these concepts as follows. The specification for this case 
can be developed for the case of closed parallel execution. We have 

Open_ParalIeI_Activities (a^aj: ACTIVITY) Boolean 

Acquisition_Activity_Start (aj: ACTIVITY; t) < 

Acquisition_Activity_Start (aj: ACTIVITY;!) 

V 
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Acquisition_Activity_Stop (aj: ACTIVITY; t) > 

Acquisition_Activity_Stop (aji ACTIVITY; t) 

ai9^aj (5.14) 

The above result has been obtained by replacing an and operator by an or operator 
to join the pre-condition clause in Eq. (5.13). 

The preceding discussion has focused on different ways parallel execution of dif¬ 
ferent acquisition activities may be addressed in the development of an acquisition 
model. 

5.7.3 Precedence Relations 

There may be cases where it is desirable to specify precedence relations for the ex¬ 
ecution of acquisition activities. Examples of this include the following: 

• An acquisition activity must be executed after some other activity. 

• An acquisition activity must not be executed after some other 
activity. 

It is possible to refine these to incorporate notions of strong and weak precedence. 
For example, strong precedence would be defined as the case where an acquisition 
activity must be executed immediately after some other activity. Weak prece¬ 
dence, on the other hand, is where there may be intervening activities between the 
(ordered) execution of two different activities. 

It is possible to develop specifications for precedence relations based on results 
specified in the framework. For example, consider the case of weak precedence for 
some activities ai and aj where activity aj must execute after activity ai. A specifi¬ 
cation of this case would be as follows: 

Weak_Activity_Precedence (aj, aj: ACTIVITY) —> Boolean 

Vt • Iiiitiate_Acquisition_Activity (aj: ACTIVITY; t) 

3 t' < t • Terminate_Acquisitioii_Activity (aj: ACTIVITY; t') 

Note that the preceding is a specification of weak precedence. It can easily be mod¬ 
ified to account for the notion of strong precedence. It is also possible to specify the 
contrary position in regard to precedence. That is, one can specify that some acqui¬ 
sition activity must not precede some other activity. 

We have not included operations in the framework for dealing with precedence of 
execution of acquisition activities. The simple reason for this is that it is possible 
to specify such conditions using operations that are already included in the frame- 
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work specification. Hence, a model can easily construct the necessary operations 
from what is provided in the framework.^^ 

5.8 Additional Considerations 

The discussion in the preceding sections has largely focused on the functional ex¬ 
tensions that may warrant consideration when developing an acquisition model 
based on the framework. There are other approaches that take a different ap¬ 
proach than that of adding functionality. The following describes some approaches 
that are based on standard formal method approaches. 

5.8.1 Promotion 

Many of the predicates described in Section 2 are specified in the context of ele¬ 
ments of a set. For example, in Section 2.3.3 we specified a predicate that indicated 
that a requirement was satisfied, that is 

Requirement_Satisfied (q: REQUIREMENT) -» Boolean ( 5 . 15 ) 

The above predicate is defined for one element of the set of requirements. We can 
promote the specification over the entire set of requirements by introducing a pre¬ 
condition in the following manner: 

AU_Requirements_Satisfied Boolean 

V Tj 6 Requirements^,] • 

Requirement_Satisfled (q: REQUIREMENT) (5.16) 

As indicated in Eq. (5.16), the predicate All_Requirements_Satisfied will be 
true iff each requirement in the set of requirements is satisfied. 

Promotion in the preceding example in Eq. (5.16) is a simple and powerful tech¬ 
nique that can be used to extend a basic specification over a larger scope. However, 
we have not included operations in the framework based on a promotion princi¬ 
ple-such as Eq. (5.16)—for a simple reason: they can be directly inferred from the 
base specification. Hence, it is not required to include them in the framework, as 
they can be easily specified when needed. 


We also do not account for the assertions that may be developed from the precedence con¬ 
siderations. For example, if activity aj must precede activity aj and activity aj must precede 
activity ai,, then it follows that activity a; must precede activity aj,. 
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5.8.2 Operational Refinement 

The first form of refinement we will briefly describe is that of operation refine¬ 
ment. In this case, one adds additional details to some operation; the details are 
typically characteristic of the model one is developing. 

Note that most of the operations defined in the framework do not have pre-condi¬ 
tions or post-conditions. This choice was made on purpose. The presence of either 
pre- or post-conditions can often represent additional levels of detail that we would 
prefer not be included in the framework because they are more specific to a partic¬ 
ular model. 

For example, consider the predicate to indicate that some requirement is satisfied. 
The meaning of such a predicate is self-explanatory (at least intuitively!), but it 
can be specified to a greater level of detail. There are different ways to state that 
a requirement has been satisfied, for example, through the use of 

• anal 5 rtic verification 

• simulation 

• system testing 

For each of the different approaches, we can define a predicate. 

Requirement_Analyzed (q: REQUIREMENT) —> Boolean 
Requireinent_SimuIated (q: REQUIREMENT) —> Boolean 
Requirement_Tested (q: REQUIREMENT) —» Boolean 

If, during the development of a particular acquisition model, one of the above ap¬ 
proaches may be considered sufficient to represent that a requirement is satisfied, 
then we can easily write: 

Requirement_Satisfied (q: REQUIREMENT) —> Boolean 

l~^ 

Requiremeiit_Analyzed (q: REQUIREMENT) v 
Requirement_Simulated (q: REQUIREMENT) v 

Requirement_Tested (q: REQUIREMENT) (5.17) 

We will not argue the validity of the semantic choice that was made above, as that 
is a property of the model. The point is, however, it is possible to add additional 
details to the specification of a model that are derived from the base framework 
specification. Stated differently, refining the specifications of the operations that 
are included as part of the framework is one approach that can (and perhaps 
should) be followed in the development of a particular acquisition model. 
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5.8.3 Data Refinement 

A second form of refinement is that known as data refinement. In this case, addi¬ 
tional details about data are added to a specification. The result is that the speci¬ 
fication becomes more concrete or, correspondingly, less abstract. 

To illustrate how the principle of data refinement can be applied, consider the case 
where we introduced a (free) data type to represent an activity, namely 

[ACTIVITY] 

The fact that the data type is declared as above means that there is no specifica¬ 
tion of either the structure or semantics of the data t 5 T 5 e. Suppose, however, that 
one wanted to develop some details of the information associated with the data 
type for the activity. Some candidate elements that can be associated with an ac¬ 
tivity might include 

• Last_Start_Time; The time when the activity was last started. 

• Cumulative_Execution_Time: The total amount of time that the 
activity has taken. 

• Current_Activity_State: An indication of the state, where the state 
could be null, in_progress, suspended, or completed. Such a model 
was used when we described the execution character of activities 
(see Section 2.4 on page 23). 

The above data types can be specified as follows: 

Last_Start_Time: Time 
Cumulative_Execution_Time: Time 

Activity_State: null | in_progress | suspended | completed 

Recall that the tyrpe time is a built-in type in the language we are using. The spec¬ 
ification of the activity state is represented as a choice, being one of the two values 
specified. 

The above data types can now be used to refine the specification of an activity in 
the following manner: 


ACTIVITY[,]: {Last_Start_Time, Cumulative_Execution_Time, Activity_State} 

The above declares that a particular activity is a set of the indicated elements. Us¬ 
ing the above it is possible to perform operations such as 
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• Whenever an activity is initiated, the time that the activity was 
started will be saved. 

• Whenever an activity is terminated, the cumulative execution time 
will be calculated and updated. Or, the most recent amount of 
execution time could be computed and saved. 

• Whenever an activity is initiated, its state is set to the value of 
in_progress, and whenever the activity is suspended, its state is set 
to suspended. 

Each of the preceding can be stated as part of the post-condition for the appropri¬ 
ate predicate. To do so we refine the notion of an ACTIVITY as follows: 

ACTIVITY[t]: sequence {Activity_State, Last_Start_Tinie, 

Cumulative_Execution_Time} 

The above simply takes the data type ACTIVITY and refines it so that an activity 
is now a sequence of data items. In particular, information about the state and the 
time the activity was last started will be maintained for each activity. 

As a simple example of how the data refinement principle can be applied, consider 
the following modification to the predicate for initiation of an acquisition activity: 

Imtiate_Acquisition_Activity (a: ACTIVITY; t) —> Boolean 

=i> 

a.Activity_State = in_progress 
a.Last_Start_Time = t 
a.Cumulative_Execution_Time = 0 

Note the use of the dotted notation in the above expression as a selector mecha¬ 
nism for the specified activity. The result is that the operation 
Initiate_Acquisition_Activity sets the value of the activity state to the value of 
in_progress, sets the time when activity was started to the current time, and ini¬ 
tializes the cumulative execution time to zero. 

The specification of the framework has not included any data refinement opera¬ 
tions. To do so would be equivalent to defining data representation and semantics 
that would be imposed on all models derived from the framework. Clearly such a 
choice would be an over-specification. It is the choice of the model developer as to 
how such data refinement would be used in a particular model development. 
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6 Summary 


In this report we have developed a general framework for the specification of ac¬ 
quisition models. The framework is intended to be minimalist in nature and is 
based on acquisition activities, events, requirements, and instances of a system as 
well as relations between these elements. 

The value of an acquisition framework is that one can develop acquisition models 
that are based on the framework, possibly with extensions. This then allows one 
to gain a deeper understanding of the behavior of the model, as well as to compare 
different acquisition models. 

We leave the reader with a final comment. The world moves ever more quickly to¬ 
ward the perspective of systems of systems. The interoperability of such systems is 
now a major issue in the ability to accomplish an overriding mission. Interopera¬ 
bility among systems is regarded as a technical issue, and rightly so. But there is 
another question that is very relevant, and we illustrate it in the following. 



Programmatic 

Interoperability 


Technical 

Interoperability 



Figure 6-1: Multi-Project Acquisition 

Figure 6-1 shows two acquisition projects, denoted A and B, whose acquisition is 
based on models A and B, respectively. It is required that the systems produced, 
denoted A and B, are required to interoperate, shown by the solid line at the bot¬ 
tom in the figure.^^ 


A diagram such as that presented in Figure 6-1 is known as a four-comer diagram. 
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Our final comment, then, is really a challenge: What does it mean, formally, to in- 
tegrate individual acquisition models, in order to achieve programmatic interoper¬ 
ability'? This is a question of serious concern, as well as ongoing work. 
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Appendix A Summary of Framework Specification 


In this Appendix we provide a summary of the mathematics used to describe the 
acquisition framework presented in Section 2. The base specification is provide be¬ 
low and it serves to reference other elements of the specification which appear on 
the following pages. 


Theory Acquisition_Frainework 

with Framework_Activities, 

Framework_Intemal_Events, 

Framework_Extenial_Events, 

Framework_Requirements, 

Framework_System, 

Framework_Relations, 

Framework_Execution, 

Frainework_Execution_Concurrency, 

Framework_Specification_Completeness, 

Framework_Execution_Completeness 

end Acquisition_Framework 
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Theory Framework_Activities 
[ACTIVITY] 

Acq_ActivitieS[,]: (ACTIVITY) 

#Acq_ActivitieS[t] > ^ 

Activity_Relation: Acq_ActivitieS[,j <-> Acq_ActivitieS[t] 

V aj, Hj G Acq_ActivitieS[,] 

• Activity_Relatlon (aj, aj) 

aj aj 

Add_Activity (aj; ACTIVITY; t, t') -> Boolean 

l=> 

Acq_ActivitieS[,] = Acq_ActivitieS{t-] U {aj} 

t>t’ 

Modify_Activity (a- ACTIVITY; t) Boolean 
DeIete_Activity (aj: ACTIVITY; t, t') -> Boolean 

l=> 

Acq_ActivitieS[,j = Acq_ActivitieS|',.j \ {aj} 
t>t’ 

Activity_Started (a- ACTIVITY; t) -> Boolean 
Activity_in_Progress (aj: ACTIVITY; t) Boolean 
Activity_Suspended (aj: ACTIVITY; t) Boolean 
Activity_CompIeted (aj: ACTIVITY; t) -> Boolean 
end Framework_Activities 
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Theory FrameworkJnternaLEvents 

[INTERNAL_EVENT] 

IntemaLEventSfi]-. {INTERNAL_EVENT} 

Create_InternaI_Event (e; INTERNAL_EVENT; t, t') —> Boolean 

l=> 

Intemal_EventS[f] = Interaal_EventS[,’] U {e} 
t>t' 

Modify_Internal_Event (e: INTERNAL_EVENT; t) Boolean 

Delete_InternaI_Event (e: INTERNAL_EVENT; t, t') —> Boolean 
1 =^ 

Intemal_EventS[j] = Intemal_EventS[t'] \ {e} 
t>t' 

lnternal_Event_Occurred (e. INTERNAL_EVENT; t) —> Boolean 

Generate_Internal_Event (e: INTERNAL_EVENT; t) —> Boolean 
|=> Internal_Event_Occurred (e; INTERNAL_EVENT; t) 

end Framework_Internal_Events 


Summary of Framework Specification 




Theory Framework_External_Events 

[EXTERNAL_EVENT] 

Extemal_EventS[t]: {EXTERNAL_EVENT} 

ExternaLEvent_Occurred (e: EXTERNAL_EVENT; t) ^ Boolean 

end Framework_ExternaLEvents 
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Theory Framework_Requirements 

[REQUIREMENT] 

RequirementS[t] : {REQUIREMENT} 

#RequirementS[[] > 0 

Add_Requirement (q : REQUIREMENT; t, t') —> Boolean 

RequirementS[t] = Requirements^t] U {q} 
t>t‘ 

Modify_Requirement (q: REQUIREMENT; t) —> Boolean 

Delete_Requirement (q; REQUIREMENT; t, t') —> Boolean 

RequirementS[t] = RequirementS[t'] \ {q} 
t>t' 

Requirement_Satisfied (q: REQUIREMENT) —> Boolean 
Requirement_Dependency (q, rj: REQUIREMENT; t) —> Boolean 
V q e RequirementS[,] • 

Requirement_Dependency (q, q: REQUIREMENT; t) 

=> 

-1 Requirement_Dependency (q, q: REQUIREMENT; t) 
end Framework_Requiremeiits 
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Theory Franiework_Systeni 

[SYSTEM] 

Systemjtj: (SYSTEM) 

System_Dependency (sj, Sj: SYSTEM; t) -> Boolean 
Requirement.Satisfied (r,: REQUIREMENT, Sjt SYSTEM; t) ^ Boolean 
SystemJnstance_Satisfied (sj: SYSTEM; t) Boolean 

l~> 

V Fj £ RequirementSjt] * 

Requirements_Mapping (rj, sj) • 

Requireinent_Satisfled (tj; t) 

end Framework_Systein 
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Theory Framework_Relations 


Internal_Event_Activity_Relation: Intemal_Events<—|->Acq_ActivitieS[t] 

V Cj G Intemal_EventS[(] • 3 aj G Acq_ActivitieS[(] 

• Internal_Event_Activity_ReIation (Cj aj) 

External_Event_Activity_Relation: Extemal_EventS[i] —> Acq_ActivitieS[t] 
3 Cj G Extemal_EventS[(], aj G Acq_ActivitieS[j] 

• External_Event_Activity_Relation (e; aj) 

Requirements_Mapping: RequirementSft] < —> System^jj 

V Tj G RequirementS[t] • V Sj G System^tj 

• Requiremeiits_Mapping (r; _ Sj)) 
end Framework_Relations 
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ThBOry Framework_Execution 

Initiate_Acquisition_Activity ACTIVITY; t) -> Boolean 
-1 Activity_in_Progress (aj: ACTIVITY; t) 

1 =^ 

Activity_in_Progress (aj: ACTIVITY; t) 

Suspend_Acquisition.Activity (aj: ACTIVITY; t) Boolean 

3 t' < t • Initiate_Acquisition_Activity (aj: ACTIVITY; t’) 

l=> 

-1 Activity_in_Progress (aj: ACTIVITY; t) 
Resume_Acquisition_Activity (aj; ACTIVITY; t) -> Boolean 

3 f < t • Suspend_Acquisition_Activity (aj: ACTIVITY; f) 

l=> 

Activity_in_Progress (aj: ACTIVITY; t) 

Terminate.Acquisition.Activity (aj: ACTIVITY; t) —> Boolean 
1 ^ 

3 f < t • Initiate.Acquisition.Activity (aj: ACTIVITY; t') 

\=> 

—> Activity.in.Progress (a;: ACTIVITY; t) 

Execute.Acquisition.Activity (aj: ACTIVITY; t, t') Boolean 

Initiate.Acquisition.Activity (aj: ACTIVITY; t) 
Terminate.Acquisition.Activity (aj: ACTIVITY; t') 

t’>t 

end Framework.Execution 
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Theo ry Framework_Execution_Concurrency 


Concurrency_Permitted (ai,aj: ACTIVITY) —> Boolean 
Concurrency_Prohibited (aj, af. ACTIVITY) —> Boolean 
Concurrency_Required (ai, aj: ACTIVITY) —> Boolean 
end Framework_Execution_Concurrency 
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Theory Frainework_Specirication_CompIeteness 

InternaI_EventS[(] n External_EventS[(] = 0 

end Franiework_Specification_Coinpleteness 
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Theory Framework_Execution_CompIeteness 

V aj e Acq_ActivitieS[(] 

3 ti > tstart • Initiate_Acquisition_Activity (a;: ACTIVITY; t}) A 

3 to < tsfop • Terminate_Acquisition_Activity (aj: ACTIVITY; 12 ) 

^stait ^ ^stop 

V Cj S Extemal_EventSp] • 

Time_of [External_Event_Occurred (Cj: EXTERNAL_EVENT; t)] ^ [^-start’ ^topl 
3 aj: ACTIVITY • 

External_Eveiit_Activity_ReIation (C; aj) 

A 

Iiutiate_Acquisition_Activity (aji ACTIVITY; t) 

^ ^ [^start’ ^stopl 

V Cj e Intemal_EventS[t] • 

Time_of [lnternaI_Event_Occurred (eji INTERNAL_EVENT; t)] G [tstart’ Istopl 
3 aj: ACTIVITY • 

Internal_Event_Activity_Relation (Cj, aj) 

A 

Initiate_Acquisition_Activity (aj: ACTIVITY; t’) 

I ^ [^tart’ ^stop] 

V rjG RequirementS[tstop] • 

Requirement_Satisfied (q; tgtop) 
end Framework_Execution_Completeness 


Summary of Framework Specification 







Appendix B A Quick Tour of the Language Nestor 


The specification of the acquisition framework presented in this paper is based on 
a language called Nestor. This language is being developed to express the seman¬ 
tics of dynamic systems. We provide here a very brief description of a subset of 
Nestor that is used in this report. It is hoped that such a description will allow 
readers who are not familiar with these concepts to gain some understanding of 
the mathematical approach we have taken. 

B.1 Overview 

An overview of the language Nestor and a process perspective for how it is applied 
is presented in Figure B-1. 
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Figure B-1: Process for Specification Development 

The four columns of the first row in Figure B-l represent the main elements of a 
Nestor specification, namely, data t 3 rpes, relations, logical predicates, and mathe 
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m^ticsl functions. Thsso can ba viswad as building blocks to craata a spacification. 
In ganaral tha procass of davaloping a spacification involves the following activi¬ 
ties: 

• Basic components: The development of a specification t3^ically 
begins with specifying basic components. These may include data 
types, relations, logical predicates, and mathematical functions. 

• Expressions: The basic specification components can be used to 
develop expressions. For example, one could write a logical 
expression that involved relations between sets, as well as pre¬ 
conditions specified in terms of a mathematical function. 

• Prornotion: Promotion is the process in which some statement, over 
a primitive data type, is generalized to other members of the data 
type. For example, an expression may be developed for an element 
of the set and then promoted to all members of the set. 

• Robustness: A complete specification must account for possible 
erroneous conditions, either in data or from an operational 
perspective. Robustness refers to the set of activities performed to 
handle such situations. 

• Collections: A collection is a S5mtactic mechanism that allows one 
to encapsulate basic components and expressions. Collections may 
be used to partition different aspects of a specification. 

• Proof assertions: It is possible to specify a theory construct that is 
another form of encapsulation mechanism. The components that 
make up the theory specification can include various statements. 

The theory constmct enables one to make assertions about the 
theory. For example, given some theory and an arbitrary 
statement, are there inconsistencies present? 

For each of the activities described above to develop a specification, there are two 
considerations that apply. These are shown by the shaded first and last columns 
of Figure B- 1 . 

• Role of time: A Nestor specification has explicit built-in support for 
time, as well as temporal operations on predicates and functions 
with respect to time. We provide such capabilities because the 
envisioned domain of this language is for d3mamic systems. 

• Invariants: There are cases where there may be a property over 
data, or operations, that must be invariant. For example, if some 
set is required to have less than a specified number of members, 
this would be expressed as an invariant. Such invariants can be 
stated at different levels of a specification. 
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It must be emphasized that the development of a specification t5^ically involves a 
refinement process. That is, from a given level of specification, one may develop 
further aspects of that specification by considering various refinement techniques. 
In Nestor these include data refinement, operation refinement, and temporal re¬ 
finement. Each successive refinement adds additional detail to the specification. 

In the sections following, we briefly describe some of the elements of the language 
that are particularly relevant to the development of the specification in this report. 

B.2 Data Types 

B.2.1 Free Types 

A free t3qje is a data type that is specified without any further consideration. Free 
types are frequently used in the construction of other data types.Such types are 
often used to denote a basic type in the language and are enclosed in brackets. For 
example, to declare a free t5q)e to denote a requirement, we define it as: 

[REQUIREMENT] 

Multiple free types can be declared in one statement. Thus, to declare data t5q)es 
for entrance and exit criteria, we may write this as: 

[ENTRANCE_CRITERIA, EXIT_CRITERIA] 

B.2.2 Sets 

A set is a collection of objects that have some relation to each other. In iVestor a set 
is represented by enclosing curly braces around the data element that comprises 
the set. For example, we introduced above the notion of a free t3q)e to represent a 
requirement. If we then wanted to be able to speak of a set of requirements, we can 
do this as follows: 

Requirements: {REQUIREMENT} 

Or, to denote sets of entremce and exit criteria, we can simply declare them as: 

Entrance_Criteria: {ENTRANCE_CRITERIA} 

Exit_Criteria: {EXIT_CRITERIA} 


More specifically, a free type denotes a set of all possible values of the defined instance. 


B A Quick Tour of the Language Nestor 

B.2 Data Types 


91 



The cardinality of a set is the number of members in the set, and is denoted by the 
S3Tnbol Thus, #Requirements denotes the number of requirements. 

If an element x is a member of a set X, then we write this as x e X. Conversely, if 
X is not a member of the set X, then this is written as x g X. 

The usual mathematical operations on sets are provided. These are summarized 
in Table B- 1 . 


Name 

Symbol 

Example 

Meaning 

Null set 

0 

A = 0 

The set A has no members. 

Union 

u 

C = AUB 

C = {c|ce Avce B) 

The members of the set C are 
members of either the set A or 
the set B. 

Intersection 

n 

C = AnB 

C = {c|c6 Aac6 B) 

The members of the set C are 
members of both sets A and B. 

Difference 

\ 

C = A\B 

C={c|cG AacG B} 

The members of the set C are 
those elements that are a 
member of set A and not a 
member of set B. 


Table B-1: Set Notation 


B.2.3 Sequences 

A sequence is a list of ordered elements. We might speak of a list of names or a list 
of addresses. In an acquisition context, we might have a sequence of actiAuties, and 
this might be declared as 

[ACTIVITY] 

Activity_List: Seq (ACTIVITY) 

Because a sequence is ordered, it allows us to reference the first or last element in 
the sequence. The first element is known as the head of the sequence and denoted 
head {Activity_List}. Similarly, the last item in the sequence, known as the tail, is 
denoted tail {Activity_List}. The number of elements in the sequence is denoted 
#{ Activity_List}. 

B.2.4 Time 

Because Nestor is being developed to handle systems that are inherently dynamic 
in nature, it is important to deal with operations related to time. Hence, it is nec- 
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essary to declare data types of type time. The word “time’ is built-in for this pur¬ 
pose; thus, for example, the following declares identifiers t and t' to be of type time: 

t, t': Time 

B.2.5 Dynamic Data Typing 

A further consideration regarding the desire to specify a d5mamic system is to rec¬ 
ognize that values of data t3rpes may change in time. The preceding causes us to 
account for what we call d3mamic data t5^ing: a declaration of a data object that 
may change in time. This is achieved by including subscripted brackets in the dec¬ 
laration of a data t3T)e. For example, if the set of requirements that we introduced 
earlier may change in time, this can be specified as 

RequirementS[t]: {REQUIREMENT} 

The presence of a subscripted [t] denotes a d3mamic data type.'^° There are two rea¬ 
sons for the explicit provision of dynamic data types. First, it is a simple reminder 
to the specification developer (and the reader) that the values of the t3q)e may 
change with time. Second, it allows for operations to be performed using the dy¬ 
namic data types at different instants of time.^"^ This ability turns out to be a very 
powerful means of reasoning over the dynamic behavior of a specification. 

For example, consider the following: 

r: REQUIREMENT 

RequirementS[t'] = Requirements^] U {r} 
t'>t 

The preceding declares some requirement called r. We then define the set of re¬ 
quirements at a time t' to be the union of requirements at an earlier time t and the 
requirement r. Note that we require f to be greater than t. 


The presence of a parameter within the subscripted brackets when a data type is declared 
is optional and carries no semantic importance. 

2^- Hence, one may think of a dynamic data type as a family of instances of a basic data type 
that are mapped onto time. For example Requirement^] and Requirement^] denotes the set 

of requirements at two different instants of time t and t'. It is in this sense that a dynamic 
data type may be considered to be a mapping of a base type onto instants of time. 
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B.3 Relations 


Relations are used to specify the association, or coupling, of two sets. For example, 
in the framework there is a set of internal events, i.e., those events that are raised 
within the scope of the acquisition project. There is also a set of acquisition activ¬ 
ities. These are declared as follows: 

[INTERNAL_EVENT] 

IntemaLevents: {INTERNAL_EVENT} 

[ACTIVITY] 

Acquisition_Activities: {ACTIVITY} 

It is desirable to specify the fact that there is a relation from an internal event to 
an acquisition activity. Frequently, this notion is depicted in a diagram, such as 
the following: 


InternaLEvents 


Acquisitlon.Activities 



Figure B-2: Relating Internal Events to Acquisition Activities 

The presence of the arrows in Figure B -2 denotes the relation between the internal 
events and the acquisition activities. 

Formally, a (binary) relation is a set of ordered pairs. The relation is characterized 
by a set of source elements (the internal events in Figure B- 2 ) known as the do¬ 
main. It is also characterized by a set of destination elements (the acquisition ac¬ 
tivities in Figure B- 2 ) known as the range. 

There are two points about the number of elements in the domain and range of a 
relation that are relevant. The first point concerns whether the relation is total or 
partial, and is defined as follows: 

• If the relation is defined for all elements of the domain, it is said to 
be total over the range. Conversely, if the relation is only defined 
for some elements of the domain, then the relation is said to be 
partial over the domain. 

• A similar remark applies to the range: If the relation is defined for 
all elements of the range, it is total over the range. Conversely, if 
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the relation is defined for some of the elements in the range, it is 
partial over the range. 

With reference to Figure B- 2 , the relation between internal events and acquisition 
activities is total over the domain (of internal events) and partial over the range 
(of acquisition activities). 

The second point concerns the number of elements of the source and destination 
sets that are a member of the relation. These are distinguished by these proper¬ 
ties: 

• If there is at least one element of the domain that is related to more 
than one element in the range, then the relation is many-to. 

• Conversely, if each element in the domain appears only once in the 
relation, the relation is one-to. 

A similar remark applies to the range: 

• If a member of the range can be related to more than one element 
in the domain, then the relation is to-many. 

• Conversely, if a member of the range can appear only once in the 
relation, then the relation is to-one. 

The relation indicated in Figure B -2 is many-to-one, total over the domain, and 
partial over the range. Although the use of figures to convey the notion of a partic¬ 
ular relation is interesting, note that such figures do not substitute for the math¬ 
ematical specification of the relation! 

The preceding concepts can be combined to give different characteristics of a rela¬ 
tion. For example, a relation may be many-to-one and total over both the domain 
and range. 

When a relation is written in Nestor, it is necessary to account for the above con¬ 
cepts. For example, we will use the relation between internal events and acquisi¬ 
tion activities to illustrate how relations are written. In this case, the relation 
would be declared as 

Iiiternal_Event_Activity_Relation: Intemal_Events <— 1-> Acquisition_Activities 
V Cj £ IntemaLEvents • 3 aj £ Acquisition_Activities 

• Internal_Event_Activity_Relation (e, aj) (B.3) 

The following is an interpretation of the relation shown above: 

• The first line declares the 

• name of the relation (Internal_Event_Activity_Relation), 

• set that represents the domain (Intemal_Events) 
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♦ set that represents the range (Acquisition_Activities) 

• characterization of the relation as denoted by the S3nnbol “<—|- 
>”. The structure of this symbol is interpreted as follows: 

• The presence (absence) of the “<” on the left-hand side 
indicates that the relation is many-to (one-to) over the 
domain. 

• The presence (absence) of the symbol “>” on the right-hand 
side indicates that the relation is to-many (to-one). 

• the presence (absence) of a “ | ” on the left-hand side indicates 
that the relation is partial (total) over the domain. 

• the presence (absence) of the “ | ” on the right-hand side 
indicates that the relation is partial (total) over the range. 

• The second line identifies the parameters in the relation, namely cj 
and aj. If a parameter is preceded by a universal quantifier S3rmbol 
(V), it means the relation is total with respect to that parameter. If 
the relation is partial with respect to a parameter, then the 
parameter is preceded by an existential quantifier ( 3 ). The symbol 

is read as “such that.” 

• The third line repeats the name of the declaration with its 
associated parameters.^® 

Note that there is a certain amount of redundancy in the declaration of a relation; 
that is, whether the relation is partial or total is indicated by the S3rmbol charac¬ 
terizing the relation (e.g., <— | ->) and the operator that appears on the second 
line of the declaration. This choice is purposeful, as the S3mibol (<— | ->) is a sug¬ 
gestive reminder of the character of the relation. 

B.4 Predicates 

Predicates are the means to specify operations in the language Nestor. A predicate 
can assume either the value true or false. There are four basic t5q3es of predicates. 
The first type of predicate is simply a declaration. For example, we can specify a 
predicate that indicates that some requirement is satisfied: 

Requirement.Satisned (r; REQUIREMENT) Boolean 


A verbal statement of the relation specified in Eq. (B.3) might be as follows: There is a re¬ 
lation called lntemal_Event_Activity_Relation that is from internal events to acquisition ac¬ 
tivities. The relation is many-to-many, total over the domain (of internal events) and partial 
over the range (of acquisition activities)." 
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In the above expression, we assume that the parameter r is of type requirement. 
The predicate can assume a Boolean value, that is, either true or false. As another 
example, we used a simple predicate to declare that some acquisition activity was 
in progress. Such a predicate was developed in Eq. ( 2 . 13 ) on page 18 , namely 

Activity_in_Progress (aj: ACTIVITY; t) —> Boolean 

Note the presence of the symbol “t” in the above predicate. When a predicate is de¬ 
clared, the parameters may include those of type time. Such parameters are iden¬ 
tified by following the semi-colon in the predicate declaration. More than one 
parameter of type time may be present. Time is a built-in data type to the lan¬ 
guage Nestor. 

The second t3q)e of predicate is a conditional predicate because it contains a clause 
that defines the condition(s) that must be satisfied in order for the predicate to as¬ 
sume the value True. For example, suppose we wanted to define an operation to 
initiate some acquisition activity at a time t. What is the pre-condition for such an 
operation? We suggest that an acquisition activity cannot be initiated unless it is 
not already in progress. This can be specified as follows: 

lnitiate_Acquisition_Activity (aj: ACTIVITY; t) —> Boolean 
1 ^ 

—1 Activity_in_Progress (a;: ACTIVITY; t) 

The symbol “ 1 —denotes the beginning of a pre-condition clause. The symbol i” 
represents negation. 

The third form of predicate is called an unconditional predicate. In this case there 
is only a post-condition clause present. We used a predicate of this t5rpe in Eq. 
( 2 . 17 ) on page 19 where we declared a predicate to create an internal event: 

Create_Internal_Event (e: INTERNAL_EVENT; t) —> Boolean 

l=> 

Intemal_EventS[t'] = Intemal_EventS[t] U {e} 

t’ >t 

The parameter e is of type INTERNAL_EVENT. The symbol “|=>” introduces the 
post-condition-clause; that is, the text appearing after the “|=>” defines the post¬ 
condition clause. The result of the post-condition clause is that the parameter e is 
simply added to the set of internal events. Note that the set of internal events is a 
djmamic data type, as indicated by the presence of the subscripted “[t]” notation. 

Finally, the last form of predicate is called a schema predicate. In this case there 
is both a pre- and post-condition specified. We used such a predicate when we 
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wanted to specify an operation to terminate an acquisition activity (see Eq. (2.32) 
on page 24). Thus, we declared the following: 

Terminate_Acquisition_Activity (aj: ACTIVITY; t) —> Boolean 

3 t' < t • Initiate_Acquisition_Activity (ai: ACTIVITY; t) 

l=> 

ActivityJn_Progress (a^: ACTIVITY; t) 

We read this as follows: The predicate Terminate_Acquisition_Activity as¬ 
sumes the value true at a time t, if there is an earlier time t' when the activity was 
initiated. If so, the predicate denoting Activity_iii_Progress assumes the value 
false. 

B.5 Expressions 

Expressions are statements in Nestor that may be constructed from predicates and 
data t3q)es and operations on those quantities. In many cases an expression can 
involve quantification of a predicate. For example, suppose one wants to specify 
that a requirement is satisfied. This predicate may be written as 

Requirement_Satisfied (r; REQUIREMENT) -> Boolean 

Now suppose there was a set of requirements that was declared as 

Requirements; {REQUIREMENT} 

The predicate Requirement.Satisfied applies to only one requirement. If one 
w^ts to specify that every requirement in the set of requirements was satisfied, 
this can be specified as 

V r € Requirements 

Requirement.Satisned (r; REQUIREMENT) 

The above is an example of a simple expression. It is also an example of what is 
called promotion, in that we have taken a predicate that applies to one element of 
a set and promoted (that is, applied) that predicate over all members of the set. 

Earlier, we indicated that predicates can be thought of as the building blocks of a 
specification. If so, then the expressions can be considered to be the glue that ties 
the building blocks together. Tliere are many cases where expressions can be ap¬ 
plied in the development of a specification. Most importantly, in the framework we 
use expressions when we develop the notion of timing completeness; see Section 
2 . 5.2 for that discussion. 
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B.6 Execution Semantics 

It is fundamentally important to distinguish between the specification per se and 
an execution of that specification. The latter refers to the operational semantics. 
We will briefly provide some discussion about this point. 

A basic premise in the language Nestor (like many formal specification languages) 
is that the execution of a particular specification statement, such as a predicate, 
is assumed to be atomic in nature. That is, once the statement enters execution, it 
completes without interruption. 

The existence of an atomicity property is especially important in the development 
of a specification. In our case, it means, for example, that when we developed the 
specification of the framework we did not have to consider possible interference be¬ 
tween operations when they execute. This means, for example, that if the predi¬ 
cate that initiates an acquisition activity were executed, during the time that the 
predicate executes (i.e., the initiation of an acquisition activity), no other predicate 
(such as one that might terminate the acquisition activity) is permitted to execute. 

The connection between the semantics of a specification and the manner in which 
that specification could be executed is often subtle. However, imposing an atomic¬ 
ity requirement allows us to develop the specification without reference to the 
manner in which the specification was executed. In other words, what the specifi¬ 
cation states is different from how that specification may be implemented. 
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Appendix C Guidelines for Model Development 


One of the basic reasons for developing the formal specification of an acquisition 
framework was to allow for the specification of acquisition models. In that sense, 
an acquisition model is an instance of the framework. Specification of different 
models allows a more formal comparison of them, as well as gaining a deeper un¬ 
derstanding of their semantics and behavior. 

In this Appendix, we provide some notes to aid others who may wish to develop a 
specification of an acquisition model based on the framework defined here. These 
are intended to provide guidance to the developer; the specification of the waterfall 
model in Section 3 on page 33 also illustrates the application of a general approach 
for a simple model. The following discussion is not intended to be a primer on the 
approach to developing formal specifications; interested readers should consult 
relevant sources for such broader information. 

A key aspect of the development of an acquisition model is identification of the 
boundary of the scope of the model. This can be more subtle than one might first 
think. The intended scope of the model determines what activities are performed 
and other associated properties the model must address, such as relations among 
activities. In the context of DoD acquisition there is a t 3 rpical hierarchy of Program 
Executive Level and Program Office level. But there is also the question of spon¬ 
sorship. And users. The list can go on; however, the critical point of the scope and 
boundary of the model must be carefully considered at the outset. 

C.1 Conformance to the Framework 

Before we discuss model-specific considerations it is worth spending some time ex¬ 
amining the notion of conformance to the framework. Recall that one of our goals 
was to be able to specify the framework such that it could be used in the specifica¬ 
tion of acquisition models. Loosely speaking, a specification of a model may add 
new data, operations, and expressions, or refine existing data, operations, and 
specifications, provided that the model does not contradict the framework specifi¬ 
cation. Some examples of these cases are described below. 

With regard to data specified in the framework, the following apply: 

• A model cannot change the specification of a framework data 
element if such a change would violate the framework. For 
example, in Eq. (2.1) on page 5 we specified that the number of 
acquisition activities must be greater than zero. Hence, it would be 
erroneous for an acquisition model to specify a contradiction to this 
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declaration (e.g., that the number of acquisition activities was 
zero). 

• A model may include specification of new data t 3 q)es that are not 
included in the framework. For example, in Section 5 we discussed 
possible extensions to the framework that involved data types not 
defined in the framework, such as entrance and exit criteria. 

• A model may refine the specification of data types that are included 
in the framework. An example of this was discussed in Section 5.8.3 
on page 70 where we added detail regarding the structure of an 
acquisition activity. Note however that dynamic data t3rpes 
declared in the framework (i.e., those with a subscript [t]) may not 
be converted to static data tjqies and vice versa. 

With regard to relations defined in the framework: 

• A model may introduce new relations, involving either new data 
types or data t 5 pes defined in the framework, provided that they do 
not contradict relations defined in the framework. 

• A model may refine the specification of a relation defined in the 
framework. Refinement of relations was not used in the 
development of the framework; an example of where this might be 
possible would be to state the constraint that a requirement applies 
to an instance of a system only if the requirement has been 
approved.^® 

With regard to operations defined in the framework the following apply: 

• A model may add new operations that are not present in the 
framework, provided such operations do not contradict the 
operations defined in the framework. 

• A model may refine the semantics of an operation that is specified 
in the framework (this is known as operational refinement). For 
example, the framework includes a predicate Requireinent_Satisned 
that indicates some requirement is satisfied. It does not, however, 
provide details of the conditions under which the requirement is 
satisfied. In Section 5.8.2 on page 69 we illustrated an example of 
how the operation might be refined in the context of a particular 
model. 

• A model is required to resolve the cases in the framework where 
there are operations whose semantics are underdetermined. There 
is only one such case in the framework where this arises. In our 


Including constraint clauses in a relation is an advanced feature of the language Nestor. 
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discussion of the semantics associated with suspending and 
terminating an acquisition activity, the specification of these 
operations was identical, i.e., underdetermined. A model is 
required to add additional material to resolve this consideration. 

See the discussion on this topic following Eq. (2.32) on page 24. 

With regard to expressions, the discussion above concerning operations applies. 
That is, the specification of a model may introduce new expressions, or refine ex¬ 
isting expressions, provided that the result does not contradict the specification of 
the framework. The principal case where expressions are defined in the frame¬ 
work is discussed in connection with model completeness (see Section 2.5 on page 
25). 

C.2 Basic Data Types 

The framework includes a number of basic data types, namely, activities, events, 
requirements, and instances of a system. Specification of these data types for a 
particular model is a good starting point. We would suggest that the following 
questions be resolved: 

• What are the basic activities that will be included in the model? 

What is the reason for the choices made? Is it relevant to separate 
these activities into different sets, such as technical and 
management activities, or other possible combinations? 

• What are the relevant events that the model should include? In 
particular: 

• What are the events that are internal to the scope of the project? 
Typical candidates here include events for reviews. 

• What are the external events that are of interest? Treatment of 
external events is of special importance because it represents 
the interaction of the project with the external environment. 

This may include the need to handle events associated with 
standards or COTS products, for example. 

• How will requirements be treated in the model? In particular, do we 
consider a single set of requirements or, perhaps, multiple, 
independent sets of requirements? The coupling of requirements, 
represented by dependency relations (or through specification of 
predicates) needs to be addressed. 

• What approach will be used to specify the system? Do we consider 
a single instance of a system, or do we include multiple instances of 
a system? The latter question is a classic differentiator between a 
waterfall model and an incremental model. 
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Developing approaches to resolve the above questions helps to point us in the di¬ 
rection in which the model development will proceed. 

C.3 Relations 

Related to the specification of basic data types is the consideration of how the dif¬ 
ferent data types are coupled. This coupling is specified by relations. In the devel¬ 
opment of the text, we indicated various basic relations that can be formed among 
the data types. 

As a guide to the development of relations it is useful to consider a table, as indi¬ 
cated in the following: 



Activities i 

Events 

Require¬ 

ments 

System 

Instances 

Activities 





Events 





Requirements 





System 

Instances 






Table C-1: Developing Relations for a Particular Acquisition Model 

Each cell in Table C-1 represents a possible source of relations that can be speci¬ 
fied for a particular model. Throughout the text we have used relations to help 
specify the framework. Many times the relations are developed from a simple dia¬ 
gram such as shown in Figure C-1: 


Source 


Destination 



Figure C-1: Simple Model for Development of Relations 

A number of items that should be considered when developing relations between 
a set of source elements and another set of destination elements (which can be the 
same, of course) are: 
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• Can multiple source elements be included in the same relation, or 
does the relation involve only one source element? 

• Can multiple destination elements be included in the same 
relation, or does the relation involve only one destination element? 

• Must the relation be defined over all elements in the set of source 
elements? 

• Must the relation be defined over all elements in the set of 
destination elements? 

The above questions are related to identifying the character of a particular rela¬ 
tion such as many-to-many or one-to-one. It also involves consideration of whether 
a relation is total or partial over the set of source and/or destination elements. 

C.4 Predicates 

Predicates are the main building blocks of the operations that are associated with 
a specification. Loosely speaking, predicates can be grouped into the following 
classes: 

• axioms: basic statements associated with the model. 

• inquiry functions: A predicate can be used to determine the state of 
some data or operation. For example, in the framework we use 
inquiry functions (a particular t 3 q)e of predicate) to determine 
whether an activity is in progress (see Eq. (2.13)) or whether a 
requirement has been satisfied (see Eq. (2.23)). 

• conditional predicates: A conditional predicate is one that has a 
pre-condition clause that specifies the conditions that must be 
satisfied in order for the predicate to be true. For example, we used 
a conditional predicate to specify that in order for an activity to be 
terminated, it must have been started at some earlier time (see Eq. 
(2.32)). 

• unconditional predicates: An unconditional predicate is one that 
has only a post-condition clause; no pre-condition clause is present. 

We used a predicate of this type when we discussed adding a 
requirement to the set of requirements (see Eq. (2.20)). 


As an advanced consideration, it is worth considering whether there are constraints in¬ 
volved in the relation. For example, does the relation hold over all elements in the source 
set or only over some (implicitly defined) subset of the source elements, where the subset 
is specified by a constraint? For example, one could define a relation between people, with 
the constraint that it holds only for people under the age of 12. 


c 
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• schema predicates: A schema predicate is a predicate that has both 
a pre-condition and a post-condition. The pre-condition clause 
specified the state that must be satisfied in order to initiate the 
operation, as described above. The post-condition clause specifies 
the operations or state that must hold upon completion of the 
operation specified by the predicate. 

As noted, predicates are used to specify operations on state data, such as the re¬ 
quirements associated with the model or operations that can be performed, such 
as initiating some acquisition activity. Identification of the necessary predicates is 
largely determined by what is desired to be stated for some aspect of the model. 

In addition to predicates, there are expressions that can be developed that assert 
some property over a specification. For example, the completeness criteria (see 
Section 2.5) for the framework are presented as expressions. In particular, the cri¬ 
terion that every external event must be associated with some activity (see Eq. 
(2.38)) is an example of a general expression. 

Given the above mechanisms that can be used to develop a specification, some of 
the questions worthy of consideration include: 

• What are the operations that can be applied to the basic data types, 
such as activities or events? For example, in Section 2.1.1 we 
included operations that create, modify, and delete a particular 
acquisition activity. Are these simple operations sufficient for 
relevant data types, or are more complex operations necessary to 
develop a model specification? 

• \^at are the operations that couple the different data types? A 
hint of the relevant operations can be obtained by assessing the 
relations. As another case, in Eq. (2.27) on page 22 we developed a 
predicate to indicate that some requirement was satisfied by an 
instance of a system. This amounts to a coupling of requirements 
and the system (instance) that manifests those requirements. 

• What are the operations that must hold over the entire 
specification? For example, when we discussed dependencies 
between requirements, say x and y, we required that for every 
requirement, if x depended on y, then y did not depend on x (see Eq. 

(2.25) on page 21). This choice was made to prevent circular 
dependencies. The fact that this is an assertion over the entire 
specification is especially important. 

Needless to say, the specification of predicates helps to bring out the operational 
nature of the acquisition model. 
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C.5 Timing Properties 

Timing properties are a crucial element in the specification of the framework and 
are equally crucial in the development of a model as an instance of the framework. 
It is consideration of timing properties that leads to a specification of the d 3 mamic 
character of an acquisition model. In particular, timing properties allow us to spec¬ 
ify which activities are serial in nature and which activities can be performed in 
parallel. 

When developing timing properties for a model, some of the relevant issues are: 

• What are the criteria for when a given activity may be initiated or 
terminated? 

• What are the criteria for when multiple activities may be 
performed at the same time? This question is especially important; 
for example, if one compares a waterfall model with a spiral model. 
Another example of where parallelism occurs is dealing with 
external events, such as may be defined for dealing with standards 
and COTS products. Some work toward this end is discussed in [5]. 

• Given the possibility of concurrent activities, what is the 
s 3 mchronization between them? For example, if a model specified 
entrance criteria that depend on multiple concurrent activities, 
what happens if one activity is complete, but another is not? 

There are various timing properties that can be associated with a particular mod¬ 
el. It was recognition of this fact that caused us to specify some of these in greater 
detail. See Section 5.7 on page 63 for some ideas on different timing properties that 
can be specified. 

C.6 Possible Extensions 

The intent of the framework specified in this report was that it be of sufficient 
breadth that it can be used to develop multiple acquisition models. At the same 
time, however, we have tried not to overly constrain the specification. It was the 
need for balance that led us to consider possible additional items that one could 
include in the specification of a model. These possible extensions were discussed 
in Section 5. 

The relation between the extensions and the basic framework specification is 
shown in Figure C-2. The center of the figure shows the (core) framework specifi¬ 
cation. It is surrounded by possible extensions, many of which were described in 
Section 5. Another item that has been mentioned in the text is how an acquisition 
model would need to account for standards and COTS products. But also shown in 
Figure C-2 is an indication that other topics can be defined as part of developing a 
specification of an acquisition model. The significance of the arrows leading to the 
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framework simply indicates that the extensions are integrated into the basic spec¬ 
ification of the framework. 



Figure C-2: Relation of Extensions to Framework Specification 

It is difficult to give specific guidance on additional specification that could be in¬ 
cluded in a particular model. Recognition of the need to state some property asso¬ 
ciated with the model is what will determine whether additional specification is 
required that is outside the scope of the core framework. Thus, treatment of exten¬ 
sions is very model dependent. 

C.7 Assertions Over the Specification 

The ultimate utility of a formal approach to the specification of an acquisition 
model is that it should be possible to reason about the specification in a formal 
manner. From a mathematical point of view, this deals with the development of 
assertions which can then be established by a proof technique. 

The ability to state, and then prove, assertions about a formal specification is very 
powerful. In the discussion of the waterfall model (Section 3.5 on page 43) we gave 
some instances where it was possible to reason about a model specification. The 
ability to pose questions about a model, and then to be able to resolve the questions 
through application of a formal approach, is very useful. While a discussion of 
proof techniques is beyond the scope of this report, we want to make the reader 
aware that such approaches do exist and are of considerable value. 
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Appendix D Additional Comments on the Waterfall 

Model 


In Section 3 we provided a specification of the traditional waterfall model in terms 
of the basic acquisition framework described in Appendix D. There is additional 
material in reference [6] concerning the waterfall model that we did not address 
earlier. In particular, the additional specification statements concerning the wa¬ 
terfall model can be viewed as refinement to the basic specification. Our goal here 
is to address the refinement issues for two topics, namely, elaboration of activities 
that are included in the model and a specification of artifacts associated with the 
model. 

D.1 Elaboration of Activities 

The activities described for the waterfall are specified at a high level. It is possible 
to refine those activities, which amounts to the addition of detail to a specification. 
In the case of the waterfall model, the activity of preliminary design included the 
following activities: 

• Document system overview. 

• Design database and processors. 

• Allocate subroutine storage. 

• Allocate subroutine execution times. 

• Describe operating procedures. 

We can declare the above items as activities as 

Document_System_Overview, Design_Database, Allocate_Subroutme_Storage, 
Allocate_Subroutine_Execution_Time, Describe_Operating_Procedures: 

ACTIVITY 

Next, we declare the above to be members of a set of design activities: 

Design_Activities = {Document_System_Overview, Design_Database, 
AIlocate_Subroutine_Storage, Allocate_Subroutine_Execution_Time, 
Describe_Operating_Procedures} 

It is now possible to relate the above activities to those defined in Section 3. In par¬ 
ticular, we earlier defined an activity for program design: 

Design_Activities Z) Program_Design 
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D.2 Artifacts 


The description of the waterfall model also included a number of artifacts that are 
created during the development process. Specification of artifacts is not part of our 
core framework; however, in Section 5.4 we described an approach to dealing with 
artifacts. 

We begin with a description of a free type to represent an artifact: 

[ARTIFACT] 

In the description of the waterfall model provided in [6], a number of artifacts are 
described. These are documents that are produced during the development effort. 
We can declare these to be artifacts as follows: 

Software_Requirements_Document, Preliminary_Design_Specification, 
Interface_Design_Specification, Final_Design_Specification, Test_Plan_Specification, 
Operating_Instructions: ARTIFACT 

We now declare a set of artifacts that we will denote as documents: 

Documents: [ARTIFACT] 


Documents: Software_Requirements_Document, Preliminary_Design_Specification, 
Inteiface_Design_Specification, FinaLDesign_Specification, Test_Plan_Specification, 
Operating_Instructions 

It is also necessary to relate the documents to a particular activity in the model. 
The character of the relation is that every document must be related to at least one 
activity, but not all activities need to have an associated document. The specifica¬ 
tion of the necessary relation is then 

Document.Relation: Documents <—1-> Activities 
3 dj e Documents, aj e Activities 
• Docuinent_Relation (dj aj) 

A declaration of the relations for the above documents with their associated activ¬ 
ities are defined as: 


Docunient_Relation (Software_Requirements_Document, Software_Requirements); 
Document_ReIation (Preliminary _Design_Specification, Program_Design); 
Document_ReIation (Interface_Design_Specification, Program_Design) 
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Document_Relation (FinaLDesign^Specification, Program^Design) 
Document__Relation (Test_Plan_Specification, Testing) 
Document_ReIation (Operating_Instnictions, Operations) 
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Appendix E Index of Mathematical Formulas 


The following index references data types and operations that appear in this re¬ 
port. Page numbers appearing in bold font are associated with the basic frame¬ 
work. 

—A— 

Acq_Activities 5 , 10 , 11 , 17 , 28 , 34, 36, 56, 58, 64, 83, 87 

Acquisition_Activity_Start 64, 66 

Acquisition_Activity_Stop 65, 66, 67 

Activities 36, 53,110 

ACTIVITY 5, 60,63,70,109 

Activity_Completed 18 

Activity_in_Progress 18 , 23 , 24 , 61, 63,78, 84,97 

Activity_Precedence 67 

Activity_Relation 10, 36, 39, 78 

Activity_State 71 

Activity_Suspended 18, 78 

Add_Activity 17 

Add_Requirement 20 

All_Requirements_Satisfied 40, 68 

Approval_Authority 53 

ARTIFACT 55,110 

—C— 

Closed_Parallel_Activities 66 
Concurrency_Pemiitted 25 , 85 
Concurrency_Prohibited 25 , 85 
Concurrency_Required 25 , 85 
COTS_PRODUCT 55 
COTS_Product_Acceptable 55 
COTS_Product_Evaluated 55 
COTS_Product_Upgraded 56 
COTS_Products 55 
Create_Intemal_Event 19 
CRITERION 57, 60 


Delete_Activity 17 
Delete_Intemal_Event 19 
Delete_Requirement 21 
Document_Relation 110 
Documents 110 
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—E— 

Entrance_Criteria 57, 58, 60 
Entrance_Criterion_Activity_Mapping 60 
Entrance_Criterion_Activity_Relation 58, 60 
Entrance_Criterion_Satisfied 58, 60 
EVENT 34 

Execute_Acquisition_Activity 25 , 41, 64, 65 
Exit_Criteria 57, 58, 59, 60 
Exit_Criterion_Activity_Mapping 60 
Exit_Criterion_Activity_Relation 58, 59, 60 
Exit_Criterion_Satisfied 58, 59, 60 
EXTERNAL_EVENT 6 , 20 
ExtemaLEvent_Activity_Relation 12 , 29 , 87 
Extemal_Event_Occurred 20 , 29 , 87 
Extemal_Events 6 , 12 , 29 , 34, 87 

“-G—- 

Generate_Internal_Event 19, 37 


Initiate_Acquisition 61 

Initiate_Acquisition_Activity 23 , 24 , 25 , 28 , 29 , 38,39,40,53, 58,60,63,64,65,67,71,84, 
87 


Initiate_Activity 63 
INTERNAL.EVENT 6 , 19 , 37 
Intemal_Event_Activity_Relation 11, 83 
Intemal_Event_OccuiTed 19 , 29 , 37,41, 87 
IntemaLEvents 6 , 11 , 19 , 29 , 34, 36, 83,87 


—M— 

Modify_Activity 17 
Modify_Intemal_Event 19 
Modify_Requirement 20,38 


—N— 

New_COTS_Product_Available 55 
NUMBER_REQUIREMENTS 35 


—-O— 

Open 66 

Open_Parallel_Activities 66 

—P— 

ParalleI_Activities 65 
PARTICIPANT 51 
Participants 53 
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Phase 60, 61, 63 
Project_Review 36,41 

—R— 

REQUIREMENT 7 , 35 
Requirement_Analyzed 69 
Requirement_Correct 50 
Requirement_Dependency 21 
Requirement_Satisfied 21 , 22 , 38,40, 68, 69 
Requirement_Self_Consistent 50 
Requirement_Simulated 69 
Requirement_Tested 69 
Requirements 8 , 13 , 21 ,35,40,68, 83 
Requirements_Consistent 50 
Requirements_Mapping 13, 83 
Resume_Acquisition_Activity 24 

““S^“ 

Sequential_Acquisition_Model 64 
Serial_Activities 64 
Suspend_Acquisition_Activity 24 
SYSTEM 35 
System 9 , 13 , 35, 83 
System_Dependency 22 
SYSTEMJNSTANCE 8 

—T— 

Terminate_Acquisition_Activity 24 , 25 , 28 , 38, 39, 59,60,61,63, 64, 65,67, 87 
Terminate_Activity 63 
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